なぜ今、PostgreSQLのGiSTインデックスを再考すべきなのか
PostgreSQLを長く触っていると、B-treeインデックスには飽き飽きしてくる瞬間があるはずだ。もちろん、等価比較や範囲検索におけるB-treeの完成度は神の領域だが、世の中はそんなに単純じゃない。GISデータ、複雑な範囲型、あるいは全文検索……。B-treeの「一次元的な世界」から脱却しなければならない時、我々は決まって「GiST（Generalized Search Tree）」という名の扉を叩くことになる。
今日は、ドキュメントの表面をなぞるような話はしない。GiSTの内部構造と、現場で「ハマる」ポイントに絞って、少しディープな話をしよう。
—
GiSTの核心：平衡木ではなく「バランスの取れた包含関係」
多くのエンジニアがGiSTを誤解している。「B-treeの多次元版」という認識だ。だが、実際はもっと過激な構造をしている。
GiSTは、B-treeのような単なる「ソート」に基づく木ではない。「述語（Predicate）」に基づく木だ。各ノードは「この枝には、このような特性を持つデータが含まれている可能性がある」という情報を保持している。
ここで重要になるのが、`penalty` 関数と `picksplit` 関数だ。
- penalty: 新しいデータを挿入する際、どの枝に加えるのが「コスト」が最小かを計算する。
- picksplit: ノードが溢れたとき、どう分割すれば検索効率が最大化されるかを判断する。
B-treeが「値の大小」という揺るぎない指標で構築されるのに対し、GiSTは「重なり（Overlap）」や「体積」といった曖昧な概念を数学的に制御してバランスを保っている。この柔軟性こそがGiSTの強みであり、同時にパフォーマンスチューニングを困難にする元凶でもある。
—
パフォーマンストラブルの「急所」
GiSTを使っていると、ある日突然クエリが劇的に遅くなる瞬間が来る。特にデータ量が増えたときだ。その際、まず疑うべきは以下の3点だ。
1. 「重なり」の爆発
GiSTは、インデックス内の各ノードがカバーする範囲が重なりすぎると、検索時に複数のパスを辿る必要が出てくる。これが「検索の効率低下」の正体だ。
- 診断法: `pgstattuple` 拡張を使って、インデックスの「空き容量」や「平均的な重なり率」を確認してほしい。もしインデックスの再構築（`REINDEX`）で劇的に速くなるなら、それは挿入の過程でノードの配置が最適化されていない証拠だ。
2. 「損失のある検索（Lossy Search）」の罠
GiSTは必ずしも正確な一致を返すわけではない。インデックスの構造上、「候補（Candidate）」を返すのが基本だ。
- 例えば、幾何データで `&&` (重なり) 演算子を使う際、GiSTは「重なっている可能性がある行」を全て抽出する。その後、PostgreSQLはヒープ（テーブル本体）にアクセスし、正確な一致を再確認（Recheck）する。
- 教訓: もしインデックスの読み取り量に対してヒープの再確認コストが高すぎる場合、GiSTのインデックスサイズそのものよりも、フィルタリングの精度が問題になっている可能性がある。
3. FILLFACTOR の調整を忘れていないか
B-treeではデフォルトのFILLFACTOR（100）で満足することが多いが、GiSTでは話が別だ。
- データの更新が頻繁なテーブルでGiSTを張ると、`picksplit` が頻発し、木のバランスが崩壊していく。FILLFACTORを80〜90程度に下げて「余白」を作ることで、再構築の頻度を抑え、ツリーの質を保つことができる。これは現場の知恵として覚えておいて損はない。
—
結局、GiSTとどう向き合うべきか
GiSTは「魔法の杖」ではない。B-treeが「精密なメス」だとしたら、GiSTは「柔軟な網」だ。その網をどう編むか（どのデータ型で、どんな演算子を使うか）を理解していなければ、網目はすぐに伸びきってしまう。
もしあなたが今、GiSTの性能問題で頭を抱えているなら、まずは「インデックスの再構築」と「クエリプランの再確認」から始めてみてほしい。特に、`EXPLAIN ANALYZE` で `Rows Removed by Filter` が多発していないか？ そこが、最適化のスタートラインだ。
PostgreSQLの深淵は、こうしたインデックス構造の理解から始まる。教科書には載っていない「木の揺らぎ」を制御できたとき、あなたのデータベースは一段上のステージへ到達するはずだ。
次は……そうだな、機会があれば「SP-GiST」の空間充填曲線（Z-order曲線など）の話でもしようか。あれもまた、面白い世界だよ。
コメント