他のバージョンの文書11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

52.3. 実装

GINインデックスは内部でキー全体に対するB-treeインデックスを持ちます。 そのキーはそれぞれインデックス対象値の要素(たとえば配列のメンバ)であり、リーフページ内のタプルはそれぞれ、ヒープポインタ全体に対するB-treeへのポインタ(PT。投稿されたツリー)か、もしリストが十分に小さければヒープポインタのリスト(PL。投稿されたリスト)です。

52.3.1. GIN高速更新手法

1つのヒープ行の挿入または更新によりインデックスへの挿入が多く発生するという、転置インデックスの本質的な性質のためGINインデックスの更新は低速になりがちです。 (各キー用のヒープ行はインデックス付けされた値から取り出されます。) PostgreSQL 8.4からGINは、新しいタプルを一時的なソートされていない、待機中の項目リストに挿入することにより、この作業の大部分を遅延させることができるようになりました。 テーブルがバキュームされた時、または、待機中のリストが大きくなりすぎた(work_memよりも大きくなった)時、初期のインデックス作成の際に使用されるものと同様の一括挿入技法を使用して、項目は主GINデータ構造に移動されます。 これは、バキュームのオーバーヘッドが追加されることを考慮したとしても、GINインデックスの更新速度を著しく向上します。 さらに、フォアグランドの問い合わせ処理ではなくバックグランド処理でこのオーバーヘッドを実行することができます。

この手法の大きな欠点は、検索時に通常のインデックス検索に加え待機中の項目リストのスキャンを行わなければならない点です。 このため、待機中の項目リストが大きくなると検索が顕著に遅くなります。 他の欠点は、ほとんどの更新は高速ですが、待機中の項目リストが"大きくなりすぎる"きっかけとなった更新は即時の整理処理を招くことになり、他の更新に比べ大きく低速になります。 自動バキュームを適切に使用することで、これらの両方の問題を最小化することができます。

一貫した応答時間が更新速度より重要な場合、GINインデックスに対するFASTUPDATE格納パラメータを無効にすることにより、待機中の項目の使用を無効にすることができます。 CREATE INDEXを参照してください。

52.3.2. 部分マッチアルゴリズム

GINは"部分一致"問い合わせをサポートすることができます。 この問い合わせは1つ以上のキーに正確に一致することは決定しませんが、キー値の合理的に狭い(compareサポートメソッドで決まるキーのソート順に従った)範囲内に一致する可能性があります。 extractQueryは、正確に一致したキー値を返す代わりに、検索される範囲の下限となるキー値を返し、pmatchフラグを真に設定します。 そしてキー範囲をcomparePartialメソッドを使用して検索します。 comparePartialは実際に一致していればゼロを、一致しないが検索すべき範囲内にあればゼロ未満の値を、インデックスキーが一致可能な範囲を超えた場合はゼロより大きな値を返さなければなりません。