【テクニカル・上級編】 GEQO (遺伝的クエリ最適化) – PostgreSQL

迷宮の探索者：PostgreSQLのGEQOと、最適化の「コスト」を巡る物語

PostgreSQLを長く触っていると、必ずと言っていいほど「悪夢のようなクエリ」に出会うはずです。

数千行に及ぶ巨大なテーブルが10個、20個と複雑にJOINされ、述語が入り乱れるSQL。開発環境では一瞬で返ってきたクエリが、本番環境のデータ量になった途端、CPUを100%使い切ったまま1時間経っても帰ってこない。

PostgreSQLのクエリプランナ（`standard_planner`）は、基本的には動的計画法を用いて、可能な限り効率的な結合順序を探そうとします。しかし、結合するテーブルが増えれば増えるほど、探索すべき組み合わせは階乗的に爆発します。そこで登場するのが GEQO (Genetic Query Optimizer) です。

今回は、この「遺伝的クエリ最適化」という、一見すると魔法のような、しかし時には諸刃の剣となる機能の深淵を覗いてみましょう。

—

なぜGEQOが必要なのか？「探索の限界」

PostgreSQLの標準的なプランナは、結合テーブル数が少ないうちは非常に優秀です。しかし、結合数が12個（デフォルト値）を超えると、全探索（またはそれに準ずる網羅的な探索）を行うのは計算コスト的に割に合わなくなります。

ここでプランナは「妥協」を始めます。全探索を諦め、進化論のメカニズムを借りて、準最適解を高速に導き出そうとする。これがGEQOの正体です。

GEQOは、実行計画を「個体」とし、選択・交叉・突然変異を繰り返すことで、限られた時間内で「そこそこ良い」計画を見つけ出します。しかし、ここには大きな落とし穴があります。それは、「そこそこ良い」が「本当に最適」とは限らないという点です。

「geqo_threshold」が握るコントロールの鍵

GEQOを制御する最も重要なパラメータは `geqo_threshold` です。この値は、「何個以上のテーブルを結合する時にGEQOを起動させるか」という閾値です。

多くのDBエンジニアは、この値をデフォルトの「12」から不用意にいじりたがります。しかし、現場の勘で言わせてもらうなら、これを闇雲に下げるのはおすすめしません。

閾値を下げすぎるリスク: 少ないテーブル数でGEQOを動かすと、本来ならプランナが見つけられたはずの「真の最適解」を、確率的な探索で見逃す可能性が高まります。
閾値を上げすぎるリスク: 結合数が多いクエリでGEQOを無効化すると、プランナが最適計画を探すために過大なCPUリソースを消費し、計画作成だけでタイムアウトやハングアップを引き起こします。

この値の調整は、あなたのアプリケーションが抱えるクエリの複雑さと、プランニングに割けるCPU予算とのトレードオフです。

パフォーマンストラブルシューティング：GEQOは敵か味方か

もし、特定の複雑なクエリが「異常に遅い」と感じたとき、真っ先に疑うべきは実行計画の「質」です。

EXPLAIN SELECT … ;

この結果を見て、もし「期待していた結合順序と全く違う」あるいは「Nested Loopで全件スキャンが選ばれている」といった現象が起きているなら、GEQOが迷走している可能性があります。

診断のステップ

1. GEQOの無効化を試す:
一時的に `SET geqo = off;` してクエリを実行してみてください。もしこれで劇的に計画が改善されるなら、GEQOがたどり着いた個体が、進化の過程で「迷路の行き止まり」にハマっていたことを意味します。
2. 統計情報の再確認:
GEQO以前の問題として、統計情報（`ANALYZE`）が古くてカーディナリティの予測が外れていることはありませんか？プランナの判断は統計情報の精度に依存します。GEQOを疑う前に、まずはここを疑うのがプロの所作です。
3. クエリの分解:
そもそも結合数が多すぎるクエリは、データモデリングの見直し対象です。中間テーブルを作ったり、ビューを整理したりすることで、結合数を減らせないか検討してください。

エンジニアとしての矜持

GEQOは、PostgreSQLの懐の深さを象徴する機能です。「完璧な計画を求める」という計算機科学的な理想と、「現実的な時間で応答を返す」という現場の要請。その狭間でバランスを取るための、非常に洗練された実装だと言えます。

しかし、GEQOに頼り切るような設計は避けたいものです。複雑なクエリを叩きつけ、データベースエンジンに「あとはよろしく」と投げ出すのではなく、どのようなプランが生成されるのかを理解し、必要とあれば補助線を引いてあげる。

そうやってPostgreSQLと対話していくことこそが、最高峰のパフォーマンスを追い求めるエンジニアの醍醐味ではないでしょうか。

もし次に、プランナが奇妙な計画を立てて悩んでいるなら、ぜひ一度GEQOの存在を思い出してみてください。あるいは、それは「もっとシンプルに書けるはずだ」という、DBからのメッセージなのかもしれませんよ。