「解けない迷宮」をどう切り抜けるか：PostgreSQLのGEQOと向き合う
PostgreSQLを長く触っていると、一度は必ずぶち当たる壁があります。そう、「結合テーブルの数が増えた途端に実行計画の生成が異様に遅くなる」という現象です。
テーブルが5つ、6つと増えていくと、プランナーは「どの順番で結合するのが最もコストが低いか」を必死に計算し始めます。このとき、PostgreSQLの標準的なプランナーは動的計画法を用いて全探索を試みます。しかし、数学の教科書で習う通り、結合数（N）が増えれば組み合わせ爆発（N!）が起こる。結合テーブルが12個を超えたあたりから、最適解を探すコストそのものがクエリの実行時間を食いつぶすという、本末転倒な事態に陥ります。
そこで登場するのが GEQO (Genetic Query Optimizer) です。今回は、この「最後の手札」について、少し深掘りしてみましょう。
—
GEQOという名の「妥協と最適化の境界線」
GEQOの本質は、遺伝的アルゴリズム（GA）を用いたヒューリスティック探索です。厳密な最適解を求めることを諦め、短時間で「十分に優秀な」実行計画を見つけ出すためのアプローチですね。
内部的には、プランナーはクエリの複雑さが一定の閾値（`geqo_threshold`）を超えると、自動的にGEQOに切り替わります。ここで面白いのは、GEQOが単なる乱数による探索ではないという点です。
- 個体群の生成: 結合の順序を染色体として表現し、初期個体を生成する。
- 進化のプロセス: 選択、交叉、突然変異を繰り返す。
- 適応度関数: もちろん、コスト見積もりがその役割を担います。
興味深いのは、GEQOが「いつ収束するか」が確率的であるという点です。ここが、私たちがGEQOを扱う上で最も慎重にならなければならない理由です。
なぜGEQOが「悪者」扱いされるのか
現場で「クエリが遅い！」という悲鳴が上がったとき、その犯人がGEQOであるケースは少なくありません。なぜか？ 理由はシンプルで、「GEQOが生成した実行計画が、全探索による最適解より明らかに劣る場合があるから」です。
これはDBエンジニアにとって頭の痛い問題です。GEQOはあくまで「近似」です。統計情報が歪んでいたり、複雑なインデックスが絡んでいたりすると、遺伝的アルゴリズムが局所解（ローカルオプティマム）に陥り、とんでもなく非効率な結合順序を「最適」だと判断してしまうことがあります。
現場でのパフォーマンストラブルシューティング：3つの鉄則
もし皆さんが、GEQOが原因と思われるパフォーマンス問題に直面したら、以下の手順で切り分けてみてください。
1. 本当に「GEQOのせい」かを確認する
まず、`set geqo = off;` を実行して、プランナーに全探索を強制させてみてください。もしこれで劇的に実行計画が改善されるなら、犯人はGEQOです。ただし、計画の生成時間自体が跳ね上がるリスクがあることは忘れないでください。
2. 統計情報の「鮮度」を疑う
GEQOが迷走する最大の原因は、実はアルゴリズムそのものではなく、入力となる統計情報の不正確さにあることが多いです。`ANALYZE` を徹底するのはもちろん、複雑なカラムの相関関係があるなら、`CREATE STATISTICS` を活用して多変量統計をプランナーに教え込んでください。GEQOは「ゴミを入れたらゴミが出てくる（GIGO）」の典型です。
3. パラメータのチューニングで「粘る」
`geqo_threshold` を闇雲に上げるのではなく、GEQOに関連するパラメータを調整するのも一手です。
- `geqo_effort`: 探索の回数や手間を調整します。値を上げれば計算時間は増えますが、より良い計画が見つかる可能性が高まります。
- `geqo_population_size`: 個体数です。これも増やせば精度は上がりますが、メモリ消費と計算時間とのトレードオフです。
最後に：GEQOとどう付き合うべきか
私は、GEQOを「PostgreSQLが持つ最後の逃げ道」だと考えています。
もし、結合テーブルが12個を超えるクエリが日常的に走るような環境なら、それはGEQOの調整でどうにかするステージを通り越しているかもしれません。クエリの分解、マテリアライズドビューの導入、あるいはデータモデリングそのものの見直し――そうした設計レベルの改善を検討すべきタイミングです。
それでもなお、複雑なクエリを投げなければならないとき、GEQOはあなたの背後で、計算爆発という「死」からデータベースを守ってくれる頼もしい存在になります。彼らの機嫌を損ねないよう、正確な統計情報という「エサ」を定期的に与えてあげること。それが、熟練したエンジニアの嗜みではないでしょうか。
皆さんのデータベースが、今日も最適な実行計画を導き出せることを祈っています。
コメント