【入門編】 GEQO (遺伝的クエリ最適化) – PostgreSQL

こんにちは！データベースエンジニアの日常へようこそ。

日々、PostgreSQLとお付き合いしていると、「SQLがなんだか遅いな？」と感じる瞬間に出会うことがありますよね。そんな時、裏側で何が起きているのかを覗いてみると、実はデータベースが「最高の実行計画」を探すために、とんでもなく頭を悩ませている……なんてことがよくあります。

今日は、そんなデータベースの「迷い」を解決してくれる、ちょっと面白い機能「GEQO（遺伝的クエリ最適化）」についてお話ししようと思います。

—

例えば、あなたが10人分の料理を一度に作らなければならないと想像してみてください。
「どの順番で野菜を切り、どのタイミングで火を入れ、どの鍋を使うか？」……組み合わせを考えると、頭がパンクしそうですよね。

データベースも同じです。特に、たくさんのテーブルを「結合（JOIN）」する時、「どのテーブルから先に読み込んで、どう繋ぎ合わせれば一番効率的か？」というパズルを解いています。

通常、PostgreSQLはすべての組み合わせを計算して、「これが一番速い！」という完璧な正解を探しに行きます。でも、テーブルの数が10個、15個と増えていくと、その組み合わせの数は爆発的に増えて、計算するだけで日が暮れてしまうんです。

全部の組み合わせを厳密に計算するのが「全探索」だとすれば、GEQOは「遺伝的アルゴリズム」という手法を使って、「そこそこ良い答え」を素早く見つけ出す、いわば「直感型のベテランシェフ」のような存在です。

生物が進化するように、ランダムにいくつかの「料理の手順（実行計画）」を作り出し、その中から優秀なものを掛け合わせたり、ちょっと変異させたりして、効率的な計画に素早く辿り着く。これがGEQOの賢いところです。

では、このGEQO、いつ使うのが正解なのでしょうか？

PostgreSQLには`geqo_threshold`という設定項目があります。これは「テーブルが何個以上になったら、全探索を諦めてGEQOに切り替えるか」を決める、いわば「諦め時」のスイッチです。

デフォルトは「12」になっています。 つまり、12個以下のテーブルなら「頑張って完璧な正解を探そう！」とし、13個以上になったら「もう計算しきれないから、GEQOで賢く乗り切ろう！」という判断を下すわけですね。

「じゃあ、この数字をいじればもっと速くなるの？」と思うかもしれません。でも、ちょっと待ってください。

GEQOはあくまで「短時間でそこそこ良い解を見つける」ためのもの。もしあなたのSQLが常に決まったパターンで、かつ時間がかかっているなら、まずはインデックスの見直しや、テーブル設計そのものを見直す方が先決なことが多いです。

GEQOは、「あまりにも複雑すぎて、計画を立てるだけで時間がかかりすぎている」という時の、最後の切り札として覚えておいてください。

—

データベースの世界でも、人生と同じで「完璧な正解」を追い求めすぎると、かえって動けなくなってしまうことがあります。

もし皆さんの環境で「特定のSQLがなぜか重いな」と感じたら、一度テーブルの結合数に注目してみてください。もしかしたら、PostgreSQLがその迷路で立ち往生しているサインかもしれませんよ。

それでは、また次回の記事でお会いしましょう！データベースとの素敵な旅を！