★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 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

57.4. GINの小技

作成と挿入

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

PostgreSQL 8.4から遅延インデックス作成が使用されるため、この勧告は必要性が薄れました。 (項57.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の制限が設定された場合、返されるセットは結果セット全体からランダムに選んだサブセットになります。

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

経験上、数千(例えば5000から20000)の値がうまく動作します。