Postgres のクエリオプティマイザは本当に賢いのか。Rohan Bansal の記事は、その問いに対して小さな open-weights モデルを使ってかなり挑んだ実験を紹介している。題材は SQL の join order と実行計画で、しかも単なるベンチマーク比較ではなく、reinforcement learning まで使ってモデルを後から鍛えたという点が面白い。データベースの内部で何が起きているのかが分かるだけでなく、LLM を「文章生成」以外にどう使うかの実例にもなっている。
記事の中心は、4Bサイズの Qwen モデルを後学習させて、Postgres のデフォルトより速い query plan を出させた、という実験だ。筆者はまず、クエリオプティマイザが何をしているのかを、IMDb データセットの例で説明する。title、movie_companies、company_name などのテーブルを結合して「2000年代に作品を出した日本企業はどこか」を調べるような SQL を考えると、同じ結果にたどり着くにしても join の順序や join algorithm の選び方がいくつもある。しかも、WHERE 句の条件がどのテーブルをどれだけ絞るかで、どの順番が有利かは大きく変わる。
筆者はこの点を、会社名の国コードが [jp] で、作品年が 2000〜2009 年に絞られるケースで示している。条件がない場合は、company_name が 100k 行、movie_companies が 2m 行、title が 1m 行でも、2つの join 順序はいずれも次の join に 2m 行を渡すので差が出にくい。だが、日本企業だけ、2000年代だけに絞ると、company_name は 5k 行、title は 200k 行まで減る。すると、company_name を先に絞る順序では最初の join が約 100k 行、次が約 20k 行で済むのに対し、title 側から入る順序では最初に約 400k 行を作ってしまう。つまり、同じクエリでも join 順序次第で 4 倍の差が出る。
さらに厄介なのは、実際のオプティマイザが見る選択肢が join 順序だけではないことだ。各 join に hash join、merge join、nested-loop join があり、outer/inner の向きもあり、各テーブルの scan 方式も sequential、index、index-only、bitmap などがある。記事では、3 テーブルのクエリだけでも 4,608 通りの実行方法がありうると説明する。Postgres は全部を総当たりするわけではなく、動的計画法や、12 join 以上では genetic algorithm で探索空間を削る。それでも難しい。
そのうえで筆者は、4B のベースモデルは最初、113 個の join-heavy クエリのうち 99 個でそもそも plan を出せなかったと書く。そこで supervised fine-tuning と agentic reinforcement learning を組み合わせ、Postgres に候補 plan を投げて実行時間を測らせ、その速さを reward としてモデルを更新した。最終的には、113 クエリ全体で 44.7% の latency reduction を達成し、初期のモデルより 81% 速い query plan を出した例もある。実験環境もかなり手作りで、2x H100 の rented node 上で vLLM と trainer を動かし、手元の 4 つの Postgres コンテナで計測したという。著者は、ノイズの多い環境で RL rollout を採点するための独自の GRPO 変種や、ページキャッシュの競合を抑える計測 rig まで組んだとしている。
一番おもしろいのは、この記事が「AI がデータベースを丸ごと置き換える」とは言っていないことだと思う。やっているのは、SQL 実行の世界で最もつらい探索問題の一部、つまり「どの順番でどう結合すれば速いか」をモデルに学ばせることだ。ここには、LLM が得意な“答えの良し悪しが機械的に測れる問題”がはっきりある。文章生成と違い、実行時間という単一の報酬で鍛えられるのは強い。
ただし、これは「モデルが賢くなった」以上に、「測定の設計が勝負だった」実験でもある。Postgres のデフォルト plan より速い候補を作るだけなら、偶然でも数回は起こる。そこから学習に使える signal を安定して取り出すには、page cache の影響を抑え、ノイズを減らし、rollout ごとの差をちゃんと見ないといけない。記事がやたら計測環境に触れているのは、地味だが核心だと思う。RL の理論より、再現できる計測のほうが難しい。
初期状態で 113 件中 99 件に plan を出せなかった、という数字はかなり重い。ここから見えるのは、4B というサイズが小さいからダメだった、という単純な話ではない。SQL の query optimization は、自然言語から正答を引くような問題ではなく、制約付きの組み合わせ最適化に近い。join order を外すと性能が落ちる、しかし探索空間は爆発する。人間から見ると「テーブルをつないでいるだけ」に見えるのに、機械から見るとかなり複雑だ。
だからこの実験は、LLM を「知識を持つ会話相手」としてではなく、「探索方針を学ぶポリシー」として使う方向をはっきり示している。しかも、教師あり学習だけでなく RL を重ねたのが大きい。実行時間という報酬があるなら、モデルは説明文を作る必要がない。速い plan を選べばいいだけだ。ここは生成AIの延長線というより、古典的な最適化問題をニューラルネットで扱う再解釈に近い。
記事を読んで感じたのは、Postgres のオプティマイザは「弱い」のではなく、むしろ現実的な近似でよく頑張っている、ということだ。探索は爆発するし、厳密解は高くつく。だから dynamic programming で剪定し、必要なら genetic algorithm も使う。それでも、選択条件やデータ分布が少しずれるだけで、良い順序を外すことがある。データベースの世界では、賢さそのものより、限られた時間でどこまで見切るかが問題になる。
この実験は、その「見切り方」を別の学習器に肩代わりさせようとしている。将来的にこうしたモデルが本番の DBMS に入るかは別として、少なくとも optimizer の一部を learned component に置き換える方向性はかなり自然だと思う。特に、ワークロードが偏っていて、同じような join-heavy クエリが何度も走る環境では効きやすいはずだ。逆に、データ分布が頻繁に変わる環境では、学習した plan の寿命が短くなる懸念もある。そこはまだ楽観しすぎないほうがいい。
この手の話はつい「4B でもここまでできた」に目が行くが、本質はそこだけではない。Postgres に候補を食わせ、実行時間で返し、そこから更新する、という接続の仕方がうまい。モデル単体の能力競争というより、DB と学習器をどうループさせるかの設計が勝っている。しかも、SFT で足場を作ってから RL で詰める流れはかなり筋がいい。
一方で、これはそのまま一般化できる話でもないと思う。クエリ最適化は評価関数が明確だが、現実の多くの業務ではそこまで綺麗に測れない。だからこそ、この実験は価値がある。AI が得意な領域を無理に広げたのではなく、測れる問題に絞って徹底的に攻めたからだ。派手さより、地に足のついた強さがある。データベースの研究としても、LLM の応用としても、かなり手応えのある一例だと思う。
参考: Training a 4B model to produce 81% faster query plans than Postgres
