結合順序の深淵：PostgreSQLのオプティマイザと「GEQO」との付き合い方
PostgreSQLのクエリプランナと長く付き合っていると、時折「なぜこいつはこんな非効率な結合順序を選んだんだ？」と頭を抱えたくなる夜があるはずです。特に、テーブル数が5つ、6つと増えてくると、プランナの挙動は一種の「ブラックボックス」のように見えてくる。
今日は、PostgreSQLが裏側でどうやって「ベストな結合順序」を導き出しているのか、そして複雑なクエリでプランナが迷走し始めた時にどう立ち回るべきか、少し深掘りしてみたいと思います。
動的計画法と「指数関数的な絶望」
基本として、PostgreSQLのプランナはデフォルトで「動的計画法（Dynamic Programming）」を用いて結合順序を決定します。これは、考えられるすべての結合順序を評価し、コストが最小になるプランを選択するというアプローチです。
しかし、ここには数学的な罠がある。結合するテーブルの数を $n$ とすると、探索空間はほぼ指数関数的に増大します。テーブルが10個を超えると、すべての組み合わせを厳密に評価するコストは、クエリの実行時間そのものを凌駕してしまう。
そこで登場するのが、`geqo`（Genetic Query Optimizer）です。
GEQO：遺伝的アルゴリズムという「妥協」
`geqo`は、遺伝的アルゴリズムを用いて結合順序を近似的に探索する仕組みです。厳密解を求めることを諦め、進化論的な手法で「そこそこ良いプラン」を短時間で見つけ出そうとする。
ここで重要なのは、「GEQOは万能ではない」という点です。
- いつ有効か: `geqo_threshold`（デフォルトで12）を超えるテーブルが結合されるような、極めて巨大なクエリを投げる際。
- なぜ危険か: 遺伝的アルゴリズムは確率論に依存するため、統計情報のわずかな変動で「プランが劇的に変わる」リスクを孕んでいます。本番環境で、昨日まで速かったクエリが今日いきなり遅くなるような「プランの揺れ」は、大抵このあたりが原因です。
もし、数表クラスの複雑な結合を日常的に行っているなら、まずは`geqo`に頼り切る前に、クエリの構造そのものを疑うべきです。
現場で「プランナを導く」ための勘所
クエリチューニングの現場において、私は「プランナと喧嘩をしない」ことを信条にしています。無理やりhint句（`pg_hint_plan`など）でねじ伏せる前に、以下の観点をチェックしてみてください。
1. 統計情報の鮮度を疑え
プランナが誤った結合順序を選ぶ最大の理由は、多くの場合「コスト見積もりの誤算」です。`ANALYZE`の頻度は適切か、相関列に対する統計（`CREATE STATISTICS`）は活用できているか。プランナは、テーブルの行数が実際と乖離していれば、どんなに賢いアルゴリズムを使っても間違った判断を下します。
2. 結合の重みを可視化する
`EXPLAIN (ANALYZE, BUFFERS)` を見て、見積もり行数（`rows`）と実際の行数（`actual rows`）がどれだけ乖離しているかを確認してください。桁単位でズレているなら、結合順序以前の問題です。まずはカーディナリティの見積もり精度を改善しましょう。
3. CTE（Common Table Expressions）の壁
PostgreSQL 12以前はCTEが「最適化の境界」となってしまい、結合順序の最適化が阻害されることがありました。今は`MATERIALIZED` / `NOT MATERIALIZED`の制御で改善されていますが、複雑なCTEがプランナの視界を遮っていないか、一度`EXPLAIN`で実行プランを注意深く読み解く必要があります。
最後に：エンジニアとしての矜持
結局のところ、データベースエンジニアの仕事は「プランナという優秀な助手に、正しい情報を与えて、最適な解を導き出させること」に集約されます。
`geqo`は強力な機能ですが、それはあくまで「計算資源の節約」という妥協点を探るための手段に過ぎません。本当にパフォーマンスを極めたいのであれば、アルゴリズムの挙動を理解した上で、プランナが迷わないシンプルなスキーマ設計と、正確な統計情報の維持を心がける。それが結局、一番の近道になるんです。
皆さんのクエリが、今日も効率的なプランで実行されることを願っています。もし何か「プランナに裏切られた」エピソードがあれば、ぜひコメント欄で聞かせてください。
コメント