全文検索を高速化するために使用できるインデックスには、GINとGiSTの2種類があります。 全文検索にはインデックスは必須ではありませんが、列が定期的に検索される場合は、通常はインデックスが望ましいことに注意してください。
このようなインデックスを作成するには、次のいずれかを行います。
GIN (Generalized Inverted Index) ベースのインデックスを作成します。
列はtsvector型である必要があります。CREATE INDEX名ONテーブルUSING GIN (列);GiST (一般化検索ツリー) ベースのインデックスを作成します。
列は、tsvectorまたはtsqueryタイプにすることができます。 オプションの整数パラメータsiglenは、署名の長さをバイト単位で決定します (詳細は以下を参照) 。CREATE INDEX name ON table USING GIST (column [ { DEFAULT | tsvector_ops } (siglen = number) ] );
GINインデックスは、好ましいテキスト検索インデックスタイプである。 転置インデックスとして、それらは、一致する位置の圧縮されたリストと共に、各単語 (語彙素) のインデックスエントリを含む。 マルチワード検索では、最初の一致を見つけてから、インデックスを使用して追加の単語が不足している行を削除できます。 GINインデックスには、tsvector値の単語 (lexemes) のみが格納され、重みラベルは格納されません。 したがって、重みを含むクエリを使用する場合、テーブル行の再チェックが必要です。
GiSTインデックスは損失性であり、インデックスが誤った一致を生成する可能性があり、このような誤った一致を排除するために実際のテーブル行をチェックする必要があります。 (PostgreSQLdoesこれは必要に応じて自動的に。) GiSTインデックスは、各ドキュメントが固定長署名によってインデックスで表されるため、損失があります。 バイト単位のシグネチャ長は、オプションの整数パラメータsiglenの値によって決まります。 デフォルトの署名長 (siglenが指定されていない場合) は124バイト、最大署名長は2024バイトです。 署名は、各ワードをnビットのストリング内の単一のビットにハッシングすることによって生成され、これらのすべてのビットは、nビットの文書署名を生成するために一緒にORされる。 2つのワードが同じビット位置にハッシュすると、誤った一致が生じる。 クエリ内のすべての単語に一致 (真または偽) がある場合、テーブル行を検索して、一致が正しいかどうかを確認する必要があります。 より長い署名は、より大きなインデックスを犠牲にして、より正確な検索 (インデックスのより小さな部分およびより少ないヒープページをスキャンする) につながる。
GiSTインデックスはカバーすることができます。つまり、INCLUDE句を使用します。 含まれる列は、GiST演算子クラスなしでデータ型を持つことができます。 含まれる属性は、非圧縮で格納される。
ロス性は、誤った一致であることが判明するテーブルレコードの不必要なフェッチのために性能低下を引き起こす。 テーブルレコードへのランダムアクセスは遅いので、これはGiSTインデックスの有用性を制限する。 誤った一致の可能性は、いくつかの要因、特に一意の単語の数に依存するため、辞書を使用してこの数を減らすことをお勧めします。
GINindexのビルド時間は、多くの場合、maintenance_work_memを増やすことで改善できますが、GiSTインデックスのビルド時間はそのパラメーターの影響を受けません。
大きなコレクションの分割とGINおよびGiSTインデックスの適切な使用により、オンライン更新による非常に高速な検索の実装が可能になります。 パーティショニングは、テーブル継承を使用して、またはサーバを介してドキュメントを配布し、外部検索結果を収集することによって、たとえば、外部データアクセスを介して、データベースレベルで行うことができる。 ランキング関数はローカル情報のみを使用するため、後者が可能です。