Postgresよりも81%高速なクエリプランを生成する4Bモデルのトレーニング
概要
- クエリオプティマイザ の品質と課題についてLeisらの研究をもとに解説
- Postgres のクエリプラン生成の難しさとその理由の説明
- 結合順序最適化 のNP困難性と組み合わせ爆発の具体例
- pg_hint_plan によるクエリプラン誘導の実験的アプローチ
- 言語モデル によるヒント自動生成の可能性とその意義の考察
クエリオプティマイザはどれほど優秀か？
- 2015年、Leisらが「クエリオプティマイザの実力」に関する研究を発表
- 10年後にも同じ問いを再調査
- 10年の研究進展にも関わらず、 理想的な最適化には未到達
- Postgres はテーブル内データの全情報を持つが、最適化は極めて難解
- 特に 結合順序最適化（join ordering） はNP困難問題
- 良いクエリオプティマイザ ：高速なプラン生成
- 検証容易性 ：良し悪しは実行時間で単軸評価が可能
- 言語モデル は検証容易なタスクに強く、強化学習で高速プラン生成行動を強化可能
実験概要：小型言語モデルを用いたPostgres最適化
- 小型オープンウェイトモデル をSFTと強化学習で後学習
- Postgresのデフォルトプラン を凌駕するプラン生成の可否を検証
- 主な成果
- 4Bモデルで113問の結合多用クエリに対し 44.7%のレイテンシ短縮
- Linuxページキャッシュ干渉を抑えた測定環境 の構築
- ノイズ耐性を持つRLスコアリング手法 の設計
- RL計算を2台に分散 （vLLM+トレーナーとPostgresコンテナ）
- 500以上のGPT-6 Astraエージェント軌跡によるオフポリシー蒸留
クエリオプティマイザの内部構造
- IMDbデータセット を例にテーブル構造を解説
- title（1M行）、movie_companies（2M行）、company_name（100k行）、company_type、kind_type
- 例：2000年代に最も多くのタイトルを出した日本企業を求めるSQL
- WHERE句の選択的述語 （フィルタ条件）がプラン選択に大きく影響
- 結合順序 例
- 3テーブル結合で2通りの有効な結合木
- カーディナリティ （行数）計算例
- フィルタ前：どの順序でも2M行を次の結合に渡す
- フィルタ後：日本企業5k、2000年代タイトル200kと仮定
- (cn'⋈mc)→100k→t'で20k行、(t'⋈mc)→400k→cn'で20k行
- 前者が4倍効率的
組み合わせ爆発と現実的な最適化の困難さ
- 結合アルゴリズム （ハッシュ、マージ、ネストループ）や順序、スキャン方式の組み合わせ
- 例：3テーブルでも 4,608通り 以上のプラン
- Postgres はすべてのプランを評価せず、動的計画法や遺伝的アルゴリズムで探索空間を削減
カーディナリティ推定の限界
- Postgres は正確なカーディナリティを事前に知ることができない
- pg_statistic テーブルの統計情報と 一様分布仮定 に依存
- 一様分布仮定が崩れると推定が大きく外れる
- 早期結合での誤推定が後続すべてに波及し、誤ったプラン選択に繋がる
Postgresの挙動を変える方法
- Postgres はコスト最小プランを自動選択
- コストモデル自体を変更するにはソースコード改変が必要
- pg_hint_plan 拡張
- SQLコメントでヒントを与え、特定のプランを強制
- 例：
/*+ HashJoin(a b) SeqScan(a)*/
- 指定通りのプランが実際に選択される
言語モデルによるヒント自動生成の意義
- pg_hint_plan を使えば、ヒント次第でより良いプランを選択可能
- 言語モデル がクエリと統計情報をもとに最適なヒントを自動生成できれば
- Postgresの限界を突破する新たな最適化手法 の可能性
- 単なるカーディナリティ推定モデルの精度向上 だけでは不十分