Hashインデックス：PostgreSQLの「忘れられた巨人」を再考する
PostgreSQLのパフォーマンスチューニングにおいて、私たちはつい反射的に「B-tree」を第一選択肢に選びがちです。それは当然の帰結です。汎用性が高く、範囲検索にも対応し、何より長年の実績がある。しかし、特定のユースケース――具体的には、巨大なテーブルに対する「完全一致検索」のみが求められるシーン――において、Hashインデックスは時としてB-treeを凌駕するポテンシャルを秘めています。
今日は、あえて「Hashインデックス」に焦点を当て、その内部挙動と実務上の立ち回りについて深掘りしてみましょう。
—
なぜ今、Hashインデックスなのか？
かつて、PostgreSQLのHashインデックスは「信頼性に欠ける」というレッテルを貼られていました。クラッシュリカバリの際にインデックスの整合性が崩れるリスクがあり、実運用に耐えうるものではありませんでした。
しかし、PostgreSQL 10での劇的な改善によって、その状況は一変しました。WAL（Write-Ahead Logging）への書き込み対応が強化され、現在ではB-treeと同等の堅牢性を備えています。もしあなたが「昔の知識」でHashインデックスを避けているなら、それは非常にもったいないことです。
Hash vs B-tree：メモリ効率と検索の論理
B-treeは階層構造を持っています。ルートからリーフまで辿る過程で、インデックスの深度に応じてページアクセスが発生します。一方、Hashインデックスは「バケット」への直接アクセスです。
- 検索効率: 等価比較（`=`）において、Hashはハッシュ関数を一度通すだけで目的のバケットを特定できます。論理的に言えば、B-treeよりもアクセス回数が少なくなる傾向にあります。
- メモリ効率: B-treeはキーの順序を保持する必要がありますが、Hashにはその制約がありません。結果として、インデックスサイズが小さく抑えられることが多く、メモリ（Shared Buffers）のヒット率向上に貢献します。
WAL負荷と「書込み」の現実
ここで、シニアエンジニアとして指摘しておかなければならない「代償」があります。
Hashインデックスは、更新負荷が集中するワークロードにおいては、B-tree以上にWALのボトルネックになり得ます。Hashインデックスの構造上、バケットが分割（Split）される際、一時的に大きな排他ロックが要求されます。更新頻度が極めて高いテーブルでHashインデックスを使用する場合、この「バケット分割のオーバーヘッド」がCPUサイクルとWAL書き込みを圧迫する可能性があることは、十分に考慮すべきです。
逆に言えば、「読み取り専用、あるいは更新頻度が極めて低い大規模な参照系テーブル」においては、Hashインデックスは最強の武器になります。
パフォーマンストラブルシューティングの勘所
もしHashインデックスを導入してクエリパフォーマンスを測定するのであれば、以下の観点をチェックリストに入れてください。
1. ハッシュ衝突の監視:
あまりに多くのキーが同一バケットに集まっていないか？ データの偏り（カーディナリティ）が低い場合、Hashインデックスは期待した性能を発揮しません。`pg_stats` で分布を確認し、ユニークに近いデータセットに対してのみ適用する勇気を持ちましょう。
2. `fillfactor` の調整:
デフォルトのままで満足してはいけません。Hashインデックスの `fillfactor` を調整することで、バケット分割の発生頻度を制御できます。ワークロードに合わせてチューニングすることで、書き込み負荷を抑えつつ検索速度を最適化することが可能です。
3. EXPLAIN ANALYZE の挙動:
`Index Scan` が発生しているか確認するのは当然ですが、`Hash Index Scan` が表示されているかを確認してください。もし期待通りに機能していない場合、型変換（例えば `text` と `varchar` の不一致など）によってインデックスが効いていない可能性を疑いましょう。
結論：魔法の杖ではないが、鋭いメスである
Hashインデックスは、汎用的なB-treeとは異なり、非常にシャープなツールです。使いどころさえ間違えなければ、クエリ実行計画を劇的に改善し、システム全体のレイテンシを削り取ってくれます。
「B-treeで十分速いから」という理由で思考停止するのではなく、データの特性とアクセスパターンを見極め、時にはこうした「玄人好みの機能」に手を伸ばしてみてください。それが、PostgreSQLを極めるエンジニアの嗜みではないでしょうか。
さて、あなたの目の前にあるその巨大なテーブル、本当にB-treeである必要はありますか？ 次のメンテナンスウィンドウで、一度ベンチマークを走らせてみることをお勧めします。
コメント