2015年，莱斯（Leis）等人追问查询优化器究竟有多好，十年后再次提出这一问题。尽管研究已多，优化器仍不理想。PostgreSQL（Postgres）本该了解表内数据，可连接排序（join ordering）已知为 NP 难（NP-hard）。验证计划好坏却不难：好计划跑得快，坏计划跑得慢。语言模型擅长可验证输出，只需沿执行时间优化，便可强化模型产生更快计划。作者实验小型 4B 模型能否比 Postgres 快 81% 的查询计划。
正文
查询优化器到底有多好？
Leis 等人在 2015 年提出了这个问题，十年后又问了一次，发现尽管研究众多，查询优化器仍远未完美。Postgres 本应最了解自身表数据，但查询优化极难，其中连接顺序确定已知是 NP-hard。不过验证计划好坏较易：好计划跑得快，坏计划慢。语言模型擅学输出可验证的任务，目标单一（查询执行时间）可化为强化信号。
我实验：小开放权重模型经 SFT 和智能体 RL 能否产出胜 Postgres 默认的计划？答案是能。亮点：
- 4B 模型在 113 个连接密集查询上延迟降 44.7%，起初 99 个生成不了计划
- 建 Postgres 测量台减缓存争用噪声
- 设计自定义 GRPO 变体在噪声环境打分
- RL 分两机：vLLM 与训练器在租用 2x H100，四 Postgres 容器在桌面机
- 用五百条 GPT-6 Astra 轨迹离策略蒸馏
查询优化器内部探秘
以 IMDb 部分表（title, moviecompanies, companyname 等）为例。查“日本公司 2000 年代出品最多标题”需三表连。无过滤时两种连接树均产生 2m 中间行。加选择性谓词：cn 滤后 5k，t 滤后 200k，mc 2m。先连 cn'⋈mc 约 100k 再连 t' 约 20k；先连 t'⋈mc 约 400k 再连 cn' 约 20k。后者多 4 倍工。
组合爆炸
每连接可用哈希、合并、嵌套循环三种；计交换性三表有 8 种组合。表扫描有顺序、索引、仅索引、位图四种，共 4608 种方式（低估，因可并行）。Postgres 用动态规划与遗传算法剪枝。
多表连接搜索空间剧增，如五表查询。
估算而非计数
Postgres 不能精确计数，只能查 pg_statistic 估基数，假设列间均匀分布。该假设失败则估计错：若日本公司实际负责 50% 电影，原估 100k 变 1m，选错序。早期坏估计沿树传播污染全部。
如何引导大象
用 pghintplan 扩展，SQL 前加注释 hint 指定哈希连接、顺序扫描等，计划即遵从。
问题定义
能否让语言模型生成 hint 得更好计划？
有用研究
设想一：给模型同 Postgres 信息建基数估计器，不值。设想二：针对重分析负载，同查询反复跑，训模型找更好跑法，摊薄成本。目标是对反复跑的查询超越默认。
模型及其框架
选 4B 模型 Qwen3.8-4B-Distill（Empero 蒸馏）。建 qo-agent 赋六工具：inspectrelation、getcolumnstats、getplan、evaluatecandidate、keepdefault、finish。代理出 PlanAction JSON 编译为 hint。
示例轨迹：代理取默认计划，提 c1（树 cn⋈mc 再⋈t，哈希，118ms，0.91x），c2（树 t⋈mc 再⋈cn，嵌套循环加索引，87ms，1.24x），c3（同 c2 树哈希，100ms，1.08x），终选 c2。
基准
Join Order 基准
Leis 等提 JOB，用 IMDb，113 查询 33 模板。模板定连接骨架，查询改谓词。如模板 2 问某国公司带关键词电影，衍生 2a（德）、2d（美）。
基数估计基准
CEB 同库，约 13.6k 合成查询 16 模板。
训练时与测试时
CEB 训，JOB 验。目的就是学好该库，防 CEB 训练过拟合 JOB 模板。
查询拓扑映射
拓扑为去别名连接图。CEB 与 JOB 拓扑无重叠，无需滤。JOB 33 拓扑，CEB 12 拓扑。
如何给大象降噪
FLOPper：16 核 64G 内存，IMDb 8.5GB。Postgres 缓存页。需去噪。
校准：4 容器各 4 核 8G 跑 113 查询，预热后测 20 次。用 EXPLAIN BUFFERS 看 SHB/SRB。128MB shared_buffers 时 SRB 不归零，job-13b 测分两簇：14 次 186–204ms，6 次 227–253ms，CV 10.3%。
为防骗，跑三对交错 (候选,默认) 取中位比，差 5% 内平局。job-13b 约 20% 概率幻影加速。脚本算欺骗率：128MB 时平均 no-op 错率 5.0%/5.4%，p90 查询 13%/20%。
调优 Postgres
调 sharedbuffers 与 workmem：2GB shared_buffers 使 SRB 零，no-op 错率降至 ~1.5%，job-13b CV 0.9%，总时 95s 降至 60s。锁定 2GB/4MB。
基线与指标
几何平均加速
各查询等权，两查询一快 2x 一慢 0.5x 则几何均 1.00x。
总工作负载加速
总时长比，上例 1.4x。
前沿智能对照
10 个 JOB 查测 GPT-6 Astra 与 Qwen3.8 2.4T。Astra 中推理 5 候选：几何 2.54x，总 2.12x，回归 0。证可行，用多轮。
原始 4B 基线
5 候选下 113 中仅 15 有效，6 计划新颖有效，5 个加速 1.02–1.30x，1 个 0.05x。常见错：JSON 无效、连接树缺关系等。
通过监督微调的离策略蒸馏
先让模型学框架语言。离策略蒸馏：学生模仿教师轨迹逐 token 损。用渲染、损失掩码、展开。LoRA 仅 21.2M 参数。
教师选 Astra（上下文短），用摘要轨迹。120 条（100 训 20 验）训 1 轮有效 48/113 但几何 0.72x；2 轮后 85 有效几何 1.08x；3 轮退 0.82x。补 320 条再训，终几何 1.16x，胜 20 负 5。
渲染、损失掩码与展开
轨迹需转模型 token 格式（渲染），仅对模型应预测 token 算损（掩码），拆为 (上下文,回复) 对训。
低秩适配（LoRA）
冻主权重，训小矩阵对。4B 模型 46.6 亿参，LoRA 仅 2120 万参 42.5MB。
教师模型选择
Astra 上下文短但 API 不供推理迹，仅摘要；Qwen3.8 2.4T 开放权重视供迹但长。虑蒸馏摘要可能损，先试 Astra 迹。120 迹训后有效。
让 4B 模型擅长查询优化
智能体强化学习
在框架内跑策略 N 次，按验证标准打分，相对优势更新。
设计每轮奖励与相对优势
初奖励：加速比对数，无效罚 0.1，同默认罚 0.05，无候选罚 3，致模型怕错返默认。GRPO 相对组均反而强化默认。
改奖励：裁剪加速比，软阈 0.05，keep_default 得 0，无候选罚 0.1，同默认罚 0.02。改 anchored GRPO：以默认时间为锚，无优于默认则全负优势。
训练开始
FLOPper 跑 Postgres，H100 训推，Tailscale 连。初合并 SFT 适配器，RL 学习率 1e-6 批 8 滚 4，120 更新后几何 1.14x 无效。调 1e-5 批 16 滚 8，600 更新；改异步租 Postgres worker 使 20 并发。两次 600 更新：600 有效 99 几何 1.35x 总 1.16x；1200 有效 101 几何 1.41x 总 1.29x。每查询三滚取佳：几何与总均 1.81x，延迟降 44.7%。
成本
租 H100 $800，Astra API $400，共 $1200。
结论
4B 模型从不懂框架到连接密集负载上 1.81x 几何均加速、总延迟降 44.7%。小模型不可轻看。
下一步
探 Bao 式 hint 扫描、同策略蒸馏、轨迹反转、EC2 测噪声。
评论
多数读者质疑使用小型模型优化查询计划的实际效用与透明度，分歧主轴集中在结果确定性、训练成本计入方式以及蒸馏带来的合规风险。
机器学习优化缺乏确定性与验证手段
- 传统查询优化本应确定性执行，读者怀疑模型生成的计划能否准确完成查询意图，且难以验证其正确性。（较多人） > 优化不应该是确定性的吗？（@kingjimmy）
训练与维护成本被低估且未计入基准
- 读者推算作者耗费高昂算力与大量时间微调，怀疑基准测试未包含前期开销，并质疑生产中定期重训模型确保计划质量是否划算。（少数人） > 我怀疑他们没把那约95小时的训练时间算进基准数字里。（@Someone）
公开蒸馏声明会引来合规麻烦
- 文章称通过蒸馏轨迹证明大模型价值，读者指出这在闭源开源对立下易招致侵权指控。（少数人） > 承认这种蒸馏行为，会不会因为各大模型间的蒸馏指控而惹上麻烦？（@devsda）
文章篇幅过长难以通读
- 有读者抱怨技术报告写作冗长，阅读时间成本过高。（少数人） > 为啥这文章这么长，光看完就得花五天。（@coolThingsFirst）
基于其他模型已有相似想法
- 个别读者称曾基于其他模型产生相近构思，侧面反映该方向有一定社区关注度。（少数人） > 有趣的是我昨天基于另一模型就在想非常类似的事。（@foota）