なぜ、PostgreSQLのオプティマイザは時々「迷子」になるのか —— GEQOと付き合うための作法
PostgreSQLのクエリ最適化エンジンと長く付き合っていると、避けては通れない壁があります。そう、「結合テーブル数が増えたときのプラン生成コスト」です。
テーブルが3つや4つなら、オプティマイザは全探索（Dynamic Programming）で最適な結合順序を弾き出せます。しかし、これが10、15と増えていくとどうなるか。組み合わせ爆発によって、プラン生成そのものが計算資源を食いつぶす「本末転倒」な状況に陥ります。
そこで登場するのが GEQO (Genetic Query Optimizer) です。今日は、この一見「魔法の杖」のように見える機能の正体と、現場で遭遇するトラブルの裏側について少し深く掘り下げてみましょう。
—
GEQOの正体：確率論で「ほどほど」を狙い撃つ
GEQOは、その名の通り「遺伝的アルゴリズム」を用いた最適化手法です。全探索を諦める代わりに、個体群を進化させることで、そこそこ優秀なプランを短時間で見つけ出そうとするヒューリスティックなアプローチをとります。
ここでエンジニアとして押さえておきたいのは、「GEQOは最適解を探すためのものではない」という事実です。
- 全探索（通常モード）: 組み合わせの海を泳ぎ切り、数学的に最もコストの低い道を見つける。
- GEQO: 遺伝的アルゴリズムというメタヒューリスティックを用いて、探索空間を切り詰め、許容できる範囲のプランを高速に選ぶ。
この「許容できる範囲」という部分が曲者です。PostgreSQLのオプティマイザが「もう全探索は無理だ」と判断する閾値、それがパラメータ `geqo_threshold` です。デフォルトは12ですが、これに達した瞬間、オプティマイザは急に「大雑把」になるわけです。
—
パフォーマンストラブルの現場：なぜ「突然遅くなる」のか
現場でよくある相談の一つに、「特定のSQLが突然、異常に遅いプランを選ぶようになった」というものがあります。このとき、ログを紐解くと `geqo` が有効になっていた、というのは「あるある」です。
なぜGEQOが悲劇を招くのか。それは以下の二点に集約されます。
1. 統計情報の欠如による誤った進化:
GEQOは個体の生存戦略としてコストを評価しますが、その前提となる統計情報が不正確であれば、そもそも「何を最適とするか」の基準が歪みます。全探索なら多少の歪みはカバーできるケースもありますが、GEQOは進化の過程で「誤った局所最適解」に固定されてしまうリスクが高いのです。
2. パラメータの「気まぐれ」:
デフォルトの閾値（12）は、現代のハードウェア性能からすると少々保守的すぎると感じることがあります。しかし、安易にこの閾値を上げれば、今度はプラン生成のオーバーヘッドがクエリの実行時間そのものを圧迫します。
—
実践的なチューニング：どう付き合うべきか
僕が現場でよく勧めるのは、以下の3つのステップです。
1. そもそも結合しすぎではないか？
GEQOに頼る必要があるということは、そのSQLの設計自体が「複雑すぎる」というサインです。まずはビューの多重展開や、結合条件の不備を見直しましょう。テーブルを12個も結合しなければならないクエリが、本当にビジネス上の正解なのか、一度立ち止まって考えることが重要です。
2. 統計情報の鮮度を疑う
GEQOが迷走している場合、多くは統計情報が古いか、サンプルサイズが足りていないことが原因です。`ALTER TABLE … SET STATISTICS` を活用し、結合キーに関連するカラムの統計精度を上げてみてください。プラン生成の精度が劇的に改善することがあります。
3. 閾値は「慎重に」動かす
もしGEQOが悪さをしているなら、`SET LOCAL geqo = off` でその特定のクエリだけオフにして、プランがどう変わるかを見てください。もしオフにして「劇的に速いプラン」が出るなら、そのクエリだけGEQOを無効化する、あるいは閾値を調整する価値があります。
—
最後に：オプティマイザを信頼しすぎない勇気
PostgreSQLのオプティマイザは極めて優秀ですが、万能ではありません。GEQOは、計算資源の限界という物理的な制約に対する「現実的な妥協案」です。
エンジニアとして大切なのは、AIやアルゴリズムにすべてを委ねるのではなく、「なぜこのプランが選ばれたのか」という実行計画（EXPLAIN ANALYZE）の深層心理を読み解くことです。
GEQOが生成したプランが不本意なら、それはPostgreSQLが「今の統計情報とパラメータ設定では、これが限界なんです」と白旗を上げている証拠。その時こそ、我々エンジニアの出番です。インデックスの設計、統計の精度、そしてクエリの書き換え。それらを武器に、オプティマイザと一緒に理想のプランを導き出していきましょう。
もし皆さんの環境で「GEQOでハマった経験」があれば、ぜひ教えてください。この「深淵」を覗き込むような作業こそ、DBチューニングの醍醐味ですから。
コメント