训练一个 4B 模型，使其生成比 Postgres 快 81% 的查询计划

原文 ↗ Hacker News 讨论 ↗

一篇博客声称，一个 40 亿参数的语言模型可以为 PostgreSQL 生成查询计划，并在一个小型、内存中的基准测试上实现约 81% 的速度提升，这引发了关于 LLM 是否适合进入数据库核心优化路径的争论。评论者质疑重训练模型的实用性、性能声明中是否遗漏了规划时间，以及在狭窄工作负载上过拟合的风险，同时指出传统的基于代价和机器学习的启发式方法在面对变化的数据分布时也已经很吃力。许多人认为，LLM 更适合离线或混合式用法——例如为问题查询生成 hints——而不是在高吞吐、真实世界系统中取代成熟、确定性的 planner。

正确性以及 LLM 实际控制的内容

  • 几个人问，你怎么知道 LLM 生成的计划仍然能计算出正确的查询结果。
  • 说明：LLM 并不重写 SQL；它只是在调整 planner 设置/提示（hints）。Postgres 仍会验证计划的有效性，并在这些提示不对应合法计划时回退。
  • 有人建议做等价性检查或证明工具，但也有人指出，在一般情况下，完全证明等价性是不可判定的/NP-hard。

确定性、统计信息与工作负载漂移

  • 查询计划并不是确定性的；它们取决于统计信息、参数值以及数据形态。
  • 真实世界的工作负载常常会在统计信息变化或出现罕见的基数模式时，突然出现计划回退。
  • 当数据分布或工作负载发生漂移时，提示或学习到的计划可能失效，这限制了“一次搞定”的离线优化价值。

性能声明与基准真实性

  • 多位评论者质疑 81% 的加速：
    • 数据集很小（8 GB），能放进内存，查询是预热过的，只是只读 SELECT。
    • 担心对这种环境过拟合，以及缺乏在大型、不断演化的 OLTP/HTAP 系统上的证据。
    • 有人指出，仅仅是 Postgres 参数调得不当（例如 random_page_cost、缺少索引/统计信息）就能解释很大的差距。
  • 也有人指出，该项目忽略了规划延迟；实用的 planner 必须在实时约束下同时改进“规划 + 执行”。

LLM 与其他方法

  • 许多人认为，经典机器学习或专门的神经网络（AlphaGo 风格的启发式、GNN）比通用 LLM 更合适。
  • 诸如基于代价的优化、Postgres 直方图、GEQO，以及编译器中的学习型启发式等现有工具，被提为更有针对性的先例。
  • 有人认为 LLM 过于重型且难以调试；也有人认为它们适合离线探索，并蒸馏成更小的模型。

运行风险与使用模式

  • 对于把一个 4B 参数模型放进生产关键数据库路径，尤其是在高 QPS 下，存在明显怀疑。
  • 更多人对离线或测试时使用更感兴趣：克隆生产环境，分析慢查询，生成 hints，把它们提交到版本控制，并通过测试验证。
  • 但关于非确定性、回归风险，以及管理基于 LLM 组件的数据库团队所需技能不匹配的问题，仍然存在担忧。

其他主题

  • 讨论了对 join/sort 进行 GPU 加速 versus 更聪明的 planner 的可能性。
  • 提到自适应查询计划（运行中途切换计划）作为更长期的“终局”。
  • 还有一场关于蒸馏伦理和更广泛 AI 生态的旁支争论，同时也有人称赞这篇文章写得清晰、视觉质量高。