4B模型让查询计划比Postgres快81%
Training a 4B model to produce 81% faster query plans than Postgres
查询优化器真的足够聪明吗？尽管十年间研究不断，Postgres的优化器在复杂场景下仍显力不从心。我尝试训练一个4B参数量的模型，通过监督微调（SFT）和代理强化学习（RL），让它生成比Postgres默认方案更快的查询计划。实验结果令人振奋：在113个复杂连接查询中，该模型实现了44.7%的延迟降低，甚至在99个原本无法生成计划的案例中成功输出。我们构建了专用的Postgres测量环境，设计了抗噪的GRPO变体，并利用vLLM和H100节点完成了训练。这项研究证明，小模型在特定任务上确实能超越传统数据库优化器。
语言模型特别擅长学习那些输出易于验证的任务。
HN 评论区
143- refibrillator
“查询计划比 Postgres 快 81%”……这是在完全能放入内存的 8 GB 数据集上测的，shared_buffers 被限制为其中的一小部分，测量前已预热查询，且仅针对只读 SELECT 语句。
我对过度拟合持谨慎态度，很难说在大规模场景下，面对更真实的 OLTP 负载时，这些查询计划是否真的比 Postgres 的启发式规则更优。
无论如何，这就是基于性能分析（profile guided）优化的常态。我们很多人也明白数据库负载会随着时间和规模的变化而漂移。
向作者致敬，亲自动手并记录了他们的实验过程。
- 2001zhaozhao
工程师：“救命，我们的生产库卡在这个以前运行正常的查询上了！”
基础设施团队：“嗯，让我查查……哎哟，看来你的 LLM 查询规划器平时都挺好用，生成的查询也很快，但这次你改了一个变量名触发了查询重建，它恰好产生了幻觉，漏掉了一个索引。你能不能多跑几次 LLM，直到拿到一个更快的查询？”
- hamilyon2
最优计划的构建涉及大量数学和算法，甚至因负载而异。还有诸如创建即时索引（just-in-time indexes）等选项，这意味着解空间的增长速度比文章中呈现的还要快。有时，查询规划器本身就是总执行时间中较慢的部分。
在这里使用 LLM 有点像用钝器。我反而在期待类似 AlphaGo 风格的神经网络启发式算法。
- devsda
> 前沿智能极其强大；我从 Astra 轨迹中进行的蒸馏足以证明大模型不会消失
承认这一点会不会招致麻烦？毕竟关于闭源模型和开源模型之间相互蒸馏的指责已经满天飞了。
- rand_r
终极目标是自适应查询计划。
即使拥有所有正确的索引，初始计划也无法保证最优，一个主要原因是表统计信息并不完美。例如，你可能会跟踪某一列的相关性（该列的逻辑排序与其在堆中的物理排序的匹配程度），但这不会细化到每个值层面。邮政编码 X 可能相关性很高，而你在查询中使用的邮政编码 Y 可能完全无关。
理想的解决方案是：先选择一个初始计划，然后在执行查询读取数据的过程中，更新一个临时的、针对该查询的统计模型。接着定期重新评估是否有更快的替代计划，并以一种不丢弃当前部分结果的方式切换到新计划。
当然，中途切换计划非常复杂，但 Oracle 和 SQL Server 都支持此功能，希望 Postgres 未来也能加入。
- sgarland
除非被省略了，否则任何表上除了主键（PK）外都没有其他索引，也没有额外的统计信息。这里存在相关列：某个国家在特定年份范围内可能因为电影产业的建立而生产了更多电影；某个国家可能生产的电视剧比电影多，等等。
几乎每次我看到有人对查询使用提示（hints），都是因为他们的统计信息不正确。添加提示只是掩盖问题，如果数据结构发生变化，日后可能会适得其反。
- Someone
> 我花了约 800 美元从 Lambda 租用了一个 2x H100 SXM 节点，租期约 95 小时，还花了约 400 美元的 OpenAI API 费用来生成 Astra 轨迹演示。
> 一个微小的 4B 模型从无法理解其被封装的测试框架，到在连接密集的 SQL 查询负载上实现了 1.81 倍的几何平均加速，总延迟降低了 44.7%。
我在文章中没找到（可能扫得太快），但我怀疑他们没有把那约 95 小时计入基准测试数据。
我想所有数据库厂商都知道，如果他们能花大量时间推导查询计划，他们的查询优化器本可以做得更好。
⇒ 这可能对某些负载有用，但即便如此，你能负担得起时不时花几个小时来更新你的 4B 模型，以确保它仍然能选出好的查询计划吗？
- BirdieNZ
这是一篇非常愉快的阅读体验，无论是写作还是呈现方式。我特别喜欢它的写作水平，因为它介绍了很多高级主题，但难度刚好适合像我这样非 AI 研究背景的工程师理解到底发生了什么。它让我觉得 LLM 的某些元素不再是数学博士们搞的魔法，而是真正可以理解的。大概是因为这里更像是应用工程而非纯数学吧。感谢这篇精彩的帖子。