GINの小技

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 52章GINインデックス | 早送り | 次のページ

# 52.4. GINの小技

作成と挿入

  各値に対して多くのキーが挿入される可能性がありますので、GINインデックスへの挿入は低速のことがあります。 ですので、テーブルに対する大量の挿入では、GINインデックスを削除し、大量の挿入が終わった段階で再作成することを勧めます。

  PostgreSQL 8.4から遅延インデックス作成が使用されるため、この勧告は必要性が薄れました。 （項52.3.1を参照してください。） しかし非常に大規模な更新では、インデックスの削除と再作成がまだ最善かもしれません。

maintenance_work_mem

  GINインデックスの構築時間は`maintenance_work_mem`の設定に非常に敏感です。 インデックス作成時に作業メモリをより少なく使用しようとはしません。

work_mem

  既存の`FASTUPDATE`が有効なGINインデックスに対して挿入を繰り返す間、待機中の項目リストが`work_mem`より大きくなると、システムはこのリストを整理します。 観測される応答時間の変動を防ぐためには、待機中リストの整理をバックグランド（例えば自動バキューム）で起きるようにすることが望まれます。 フォアグランドでの整理処理は、`work_mem`を大きくすること、もしくは自動バキュームをより積極的に行うことで防ぐことができます。 しかし`work_mem`を大きくすることは、フォアグランドで整理処理が発生した時により長い時間がかかることを意味します。

gin_fuzzy_search_limit

  GINインデックス開発の主な目的は、スケーラビリティが高い全文検索のサポートをPostgreSQLで作成することでした。 全文検索の結果は非常に大規模な結果セットを返します。 さらに、問い合わせが非常に高頻度な単語を持つ場合、こうした状況はよく発生しますが、大規模な結果セットは有用ですらありません。 ディスクから大量のタプルを読み、ソートすることは長い時間がかかりますので、実運用レベルでは受け入れられません。 （インデックス検索自体は非常に高速であることに注意してください。）

  こうした問い合わせの実行を簡単に制御できるように、GINは返される行数に対して設定可能なソフト上限、`gin_fuzzy_search_limit`設定パラメータを持ちます。 これはデフォルトでは0です（無制限を意味します）。 非0の制限が設定された場合、返されるセットは結果セット全体からランダムに選んだサブセットになります。

  "ソフト"は、問い合わせとシステムの乱数生成器の品質に依存して、返される結果の実際の数が指定した上限より多少異なることを意味します。

前のページ | ホーム | 次のページ
実装 | 上に戻る | 制限