独立开发者Rohan Bansal在9月16日发表长文，介绍他如何把一个40亿参数的开源Qwen模型训练成Postgres查询计划优化器。模型并不改写SQL语句，而是输出pg_hint_plan扩展能够识别的连接顺序、扫描方式等提示，由Postgres自行校验并执行。在以多表连接为主的基准负载上，这套方案生成的计划相对Postgres默认规划器取得1.81倍几何平均加速，整体查询延迟总和下降44.7%，单条查询最快提升81%。这是小型开源模型在系统软件核心组件上少见的正面结果。
连接排序是NP难问题
查询优化器的难点不在执行而在决策。一条多表连接查询可以对应数量级爆炸的执行计划，仅连接排序这一项就是NP难问题，规划器只能依靠表上的统计摘要做启发式选择。Leis等人2015年的经典研究首次系统测量了主流数据库的规划失误，十年后原班团队复测发现情况依旧：统计信息过时、参数倾斜、相关列之间的相关性，都会让默认规划器在边缘场景选错索引或连接顺序，而且一旦选错，整条查询的延迟可能相差一个数量级。
Bansal把这件事拆成生成与验证两侧。执行计划好不好只看一个可验证指标，即实际运行时间，这恰好适合强化学习。他先用OpenAI前沿模型Astra生成的示范轨迹做离策略蒸馏，以LoRA低秩适配方式对Qwen 4B做监督微调，再进入智能体强化学习阶段：单条查询并行发起四次滚动，模型给出候选提示，Postgres实测后回标标量奖励，梯度把权重推向更快的计划，错误计划则在下一轮被压低概率。
成绩、成本与基准边界
基准测试使用IMDB数据集上的连接顺序基准JOB和基数估计基准CEB，数据集体量约8GB，可以整体放进内存，shared_buffers被刻意限制为其中一小部分。除1.81倍几何平均加速外，文章还报告了44.7%的总延迟下降；模型拓扑映射到提示模板后，不需要在线推理即可把提示固化下来。训练侧的账单同样具体：在Lambda租用双路H100 SXM节点约95小时花费800美元，调用Astra生成轨迹的API费用约400美元，合计1200美元左右。
HN讨论集中在方案的适用边界。有评论者指出8GB全内存数据集、预热后的只读SELECT查询与真实OLTP负载差距明显，数据分布漂移后静态提示会失效，而重新生成一轮提示需要95小时。也有人反驳这正是开发期工具的合理形态：模型只在测试阶段帮助发现规划器遗漏的计划，提示提交进版本库后由pg_hint_plan的调试日志验证是否生效，运行中的数据库完全不依赖模型服务，最坏情况只是提示失效回退到默认计划。
这个项目给小型模型的落地路径提供了一个清晰样本：不追求让模型做不可验证的决策，而是让它在昂贵的启发式生成侧搜索，再交给数据库做廉价而确定的执行校验。作者已把代码开源，下一步计划扩展到写操作负载和更大的数据规模。对数据库厂商而言，学习型优化器讨论了多年，这套约1200美元即可复现的实验把门槛拉低到了个人开发者能够独立完成的水平。