【テクニカル・上級編】結合手法の制御 – PostgreSQL

結合アルゴリズムの「強制」は、劇薬である。

PostgreSQLのクエリプランナは、数あるオープンソースのRDBMSの中でも、驚くほど洗練されたコストベースオプティマイザ（CBO）を持っています。しかし、どれだけ賢いプランナでも、統計情報の鮮度や複雑すぎる結合条件の前では、時に「明後日の方向」を向いた実行計画を生成することがあります。

そんな時、我々エンジニアの頭をよぎるのが `enable_nestloop`、`enable_mergejoin`、`enable_hashjoin` といったスイッチ類です。これらをOFFにしてプランナを強引に誘導した経験がある人も多いでしょう。

今日は、これらのパラメータとどう向き合うべきか、そして「なぜ安易に触ってはいけないのか」という深淵な話をしようと思います。

なぜプランナは「間違える」のか

まず大前提として、これらのフラグを触る前に、プランナがなぜそのアルゴリズムを選んだのかを理解する必要があります。

Nested Loop: 小さなデータセットの突き合わせには最強。インデックスが効いているなら一瞬です。
Hash Join: 大きなテーブル同士の結合で、ハッシュテーブルをメモリ（work_mem）に載せられるなら圧倒的。
Merge Join: 事前にソートされている、あるいはインデックススキャンで順序が保証されている場合に、メモリ消費を抑えつつ高速に動作する。

プランナがこれらを誤認する最大の要因は、多くの場合「カーディナリティ（行数）の見積もり誤差」です。相関サブクエリや、複雑なWHERE句、あるいは単純に統計情報が古いせいで、「100万行」を「10行」と見積もれば、プランナは自信満々にNested Loopを選択し、結果として我々のDBは悲鳴を上げることになります。

「enable_…」をオフにするという選択

トラブルシューティングの現場で、`SET enable_hashjoin = off;` と打ち込みたくなる気持ちは痛いほどわかります。しかし、これは「外科手術」ではなく「対症療法」です。

このフラグをオフにするということは、「このクエリだけでなく、データベース全体に対して、そのアルゴリズムの選択肢を奪う」という行為です。

例えば、特定のクエリのためにHash Joinを封印したとしましょう。すると、別のクエリでは本来Hash Joinが最適だったはずの処理が、強制的にMerge Joinに切り替わり、今度は別の箇所でパフォーマンスが劣化する……という「モグラ叩き」の連鎖に陥るリスクがあります。

真に高度なチューニングとは

では、どうすべきか。私が現場で実践しているアプローチをいくつか共有します。

1. プランナの「ヒント」を正す

まずは `EXPLAIN (ANALYZE, BUFFERS)` を見てください。見積もり行数（rows）と実測値（actual rows）の乖離が著しいなら、それはインデックスの問題ではなく、統計情報の問題です。`ALTER TABLE … SET STATISTICS` で特定のカラムの統計精度を上げるだけで、プランナは本来の賢さを取り戻します。

2. work_mem の適正化

Hash Joinが遅い場合、原因はアルゴリズムそのものではなく、メモリ不足による「ディスクへのスピル（一時ファイル書き出し）」であることが多いです。グローバルな `work_mem` を上げるのではなく、特定のセッションで `SET LOCAL work_mem = ’64MB’;` のように一時的にリソースを割り当てるのが、プロのやり方です。

3. pg_hint_plan という「最後の手段」

もし、どうしてもプランナが納得できない挙動をするなら、PostgreSQL標準のフラグをいじるのではなく、拡張モジュールの `pg_hint_plan` を検討してください。これを使えば、データベース全体の設定を変えることなく、特定のクエリに対してのみ「ここはHash Joinを使え」「ここはインデックスを優先しろ」と個別に指示を出すことができます。これこそが、アーキテクチャを汚さずに問題を解決する「外科手術」です。

最後に：プランナを信頼する勇気

技術者として、私たちは自分の手で制御したいという強い欲求を持っています。しかし、PostgreSQLのプランナは、数十年かけて進化してきた知性の結晶です。

`enable_…` フラグは、あくまで「検証用」のツールです。「なぜプランナはこの道を選んだのか？」という問いを深掘りし、統計情報やインデックス構成、あるいはクエリの書き方を調整する。その過程こそが、結果としてDBのパフォーマンスを底上げし、将来的なメンテナンスコストを下げることに繋がります。

安易なスイッチオフでその場を凌ぐのではなく、プランナが「なぜ」その判断を下したのか、そのロジックを読み解く。それこそが、データベースエンジニアとしての腕の見せ所ではないでしょうか。

皆さんのクエリが、今日も効率的なプランで走ることを願っています。