4B 模型把 Postgres 查询计划提速 81% — HN 讨论：这是真优化还是过拟合？
原文概要
Rohan Bansal 在博客 Training a 4B model to produce 81% faster query plans than Postgres（hn_id 49731285，662 分）里做了一个看起来矛盾但具体可复现的实验：把一个 4B 规模的开放权重模型用 SFT（监督微调）+ agentic RL（智能体强化学习）专门训练成 Postgres 的查询计划生成器，让它生成的执行计划比 Postgres 自带优化器快。
实验背景：4B 模型一开始对 99 条 join-heavy 查询生成不了任何计划。训练结束后，在 113 条 join-heavy 查询上拿到 1.81x geometric mean 速度提升，整体延迟平均下降 44.7%。整个实验烧的资源是租 Lambda 的 2x H100 SXM 节点 ~95 小时（约 800 美元），加上调用 OpenAI API 生成 500 条 GPT-6 Astra 智能体轨迹（约 400 美元）。
具体技术上，作者做了几件不太常见的事——给 Postgres 搭了一个测量装置降低 Linux page cache 在并发容器间的噪声；为 RL rollout 设计了一个 GRPO 的变体来处理环境噪声；RL 训练跨两台机器跑（vLLM + trainer 在租的 2x H100 节点上，4 个 Postgres 容器在自己的桌上）。
文章还科普了一个事实——一个 3 表 join 的 IMDb 查询，Postgres 内部其实有 4,608 种不同的执行方式（2 个 join 树 × 22 个内外顺序 × 32 个算法 × 43 个 scan），默认优化器用动态规划（外加 GEQO 遗传算法处理 12 表以上查询）做剪枝。
讨论焦点
81% 这个数字能复现吗？
第一个有人提醒「数字漂亮但测试条件可疑」：
“81% faster query plans than Postgres…on an 8 GB dataset that fits entirely in memory, with shared_buffers constrained to a fraction of that, queries warmed before measuring, and read-only SELECTs. I would be cautious about over fitting, it’s tough to say if those query plans would really be more optimal than Postgres heuristics at scale and with a bit more realistic OLTP workloads.” — refibrillator [c:49733010]
（译文：「比 Postgres 快 81%」——但测试集是 8GB、能全部塞进内存的 dataset，shared_buffers 还被限制到更小，query 是测前 warmed 过的，而且全是只读 SELECT。我对过拟合有点警觉，这些 query plan 是不是真的比启发式优，要在 OLTP 这种偏真实的工作负载里跑过才能下结论。）
赞同和怀疑两边的意见都有，但「用 GPU 跑数据库」被很快提出来：
“With a 4B parameter model that probably ran through 8GBs of RAM multiple times to run. At a certain point we should seriously talk about CUDA accelerating Postgres instead.” — dragontamer [c:49733880]
（译文：4B 模型本身大概跑了 8GB 内存好几遍。在这个点上，我们更应该严肃讨论一下 CUDA 加速 Postgres。）
dragontamer 后面展开了一长段关于 GPU sort、hash、mergepath 算法能给 join 提速的论点，被认为「还有 PG-Strom 这种老项目」：
“I remember projects like PG-Strom back in the day, very cool stuff” — voganmother42 [c:49734785]
（译文：我记得早年有 PG-Strom 这样的项目，挺有意思的。）
LLM 是不是这种问题的对工具？
最尖锐的反对意见是「为什么是 LLM」：
“Optimal plan construction is math-heavy, algorithm-heavy and vary even by workload. There are options like creating just-in-time indexes, so solution space grows even faster than article presents. Sometimes it is the query planner which is the slow part of total execution time. LLM is kind of blunt weapon to use here. I am waiting rather for alphago style neural net heuristic.” — hamilyon2 [c:49733064]
（译文：最优计划构造是数学密集、算法密集的事，而且随工作负载变化。还有 JIT 索引这种东西，搜索空间比文章里展示得还大。Query planner 有时是整个执行时间的瓶颈。LLM 在这里是钝刀子。我更愿意等 alphago 那种风格的神经网络启发式。）
“I also wondered why an LLM would be the right starting point. Why would Balzac or billions of lines of rwir code or reddit be relevant to mapping this smallish, well-defined language (SQL) to this other tiny constrained specification language (the query plan suggestions)? You could make a (relatively) tiny network and then actually pass it some relevant features of the actual data, like as numbers, not just as text returned from a tool call.” — topaz0 [c:49734151]
（译文：我也好奇为什么 LLM 是正确的起点。为什么 Balzac 或者几十亿行 rwir 代码或者 reddit，会跟 SQL 到查询计划这种小而严格的语言映射有关系？完全可以做一个相对小的网络，把实际数据的真实特征以数值形式喂进去，而不是只把工具调用返回的文本当输入。）
“It’s ultimately based on a lot of hand-written heuristics. Google has some non-LLM based machine learning technique to guide optimization heuristics in LLVM; that would be closer to what you are looking for.” — kccqzy [c:49734168]
（译文：最终还是基于一堆手写启发式。Google 在 LLVM 里有非 LLM 的机器学习来指导优化启发式，更接近你要找的方向。）
Cost estimation：Postgres 优化器的真正难题
中间有人提出「Cost Based Optimization」是优化器的本质：
“You create formulas to estimate the cost of running a given query plan. Use statistics collected about the tables (e.g. how many rows) to try to be accurate. The topic is ‘Cost Based Optimization’.” — haroldl [c:49734906]
（译文：写公式估算给定查询计划的代价，用表上收集的统计（比如行数）尽量估准。这一行的名字叫「基于代价的优化」（Cost Based Optimization）。）
Sesse__（看起来是 Postgres 圈内人）从根上反驳了 LLM 的必要性：
“If you have formulas that actually match reality, what do you need the LLM for? An optimizer is perfectly capable of finding the optimal plan if it has a perfect estimator. In fact, if you could only estimate the number of rows in each subplan perfectly, you have as good as solved the problem already.” — Sesse__ [c:49737060]
（译文：如果你有真能匹配现实的代价公式，你还需要 LLM 干嘛？如果能完美估算每个子计划的行数，问题就算解决了，优化器本来就能找到最优计划。）
而 malisper 的回应把这点拉回了更悲观的现实：
“Even if the query plan was not generated by an llm, you can’t verify it will run in an acceptable time. This is one of the biggest unsolved problems in databases” — malisper [c:49741815]
（译文：哪怕 query plan 不是 LLM 生成的，你也没法验证它跑起来时间够短。这是数据库里最大的未解问题之一。）
生产可靠性和调试性
很多评论员从工程实操的角度开炮：
“Engineer: ‘HELP, our production DB is frozen on this query that worked fine before!’ Infra: ‘Hmm, let’s check… Well would you look at that, it seems like your LLM query planner usually works and produces fast queries, but this time when you changed a variable name to trigger query rebuild, it happened to hallucinate and miss an index, would you mind re-running the LLM a few times until you get a faster query?’” — 2001zhaozhao [c:49733800]
（译文：工程师：「救命，生产 DB 卡在一个之前一直好好的 query 上！」基础设施：「让我看看……啊，你的 LLM 查询计划器平时好用，这次你改了变量名要重建查询，结果它 hallucinate 漏了个 index，能不能麻烦你把 LLM 多跑几次直到它跑出快一点的计划？」）
“That bug is fixable and verifiable. The LLM you cross your fingers till the next time the same thing happens.” — Tanjreeve [c:49736451]
（译文：那种 bug 能改能验。LLM 这种就只能交叉手指等下次再出。）
egeozcan 给了一个反向观点（被后面反驳）：
“When people say that the LLMs are a black box, it means unpredictability in unknown situations. You do structured output, input validation, output validation, lower temperature, limit decisions, RL, etc. to increase predictability to near certainty. It’s just statistics after all.” — egeozcan [c:49736648]
（译文：人说 LLM 是黑盒，指的是在未知情况下不可预测。可以用结构化输出、输入输出校验、低温度、限制决策、RL 等等把可预测性提到接近确定。说到底就是统计。）
tempfile 反对这个说法：
“None of the things you mention are guaranteed to increase the probability of correctness. You can run the LLM output through as many deterministic programs as you like, but ‘the query plan runs in acceptable time’ is not something you can verify with such a tool. Nobody knows how the LLM does it, so they cannot know how to make the LLM do it better.” — tempfile [c:49738523]
（译文：你提的这些都不能保证提高正确性。你可以把 LLM 输出过任意多遍确定性程序，但「query plan 跑在可接受时间内」这种事没法用这种工具验证。没人知道 LLM 是怎么做到的，所以没人知道怎么让它做得更好。）
训练成本和数据集漂移
作者文章里写了 ~95 小时训练时间。Someone 直接质疑：
“I paid ~$800 to rent a 2x H100 SXM node from Lambda for ~95 hours, and ~$400 in OpenAI API fees to generate the Astra trajectory demonstrations. I can’t find it in the article (may have skimmed it too much), but I suspect they didn’t include those ~95 hours in the benchmark numbers. ⇒ this may be useful for some workloads, but even then, can you afford to spend hours every now and then to update your 4B model to ensure it still picks a good query plan?” — Someone [c:49732105]
（译文：「我花了 ~800 美元在 Lambda 上租了 2x H100 SXM 节点 ~95 小时，又花 ~400 美元 OpenAI API 调用费生成 Astra 轨迹演示。」我在文章里没找到（可能漏读），但我怀疑他们没把 ~95 小时算进 benchmark 数字里。⇒ 这可能对某些工作负载有用，但即便如此，你能不能每隔一段时间花上几个小时更新你的 4B 模型，确保它还能选出好的 plan？）
hedgehog 给出一个温和的实用定位：
“I wouldn’t be very excited about adding a 4B param model to my database deployment, but using this kind of approach while testing an app to identify query reports where Postgres is leaving performance on the table seems valuable without much risk.” — hedgehog [c:49732100]
（译文：我不太想把 4B 模型塞进我的数据库部署，但用这种方法在测试阶段定位 Postgres 留性能在桌上的 query 是有价值、风险也不大 的一件事。）
cannonpalms 直接反驳这条：
“If your statistics or workload change, this approach is useless. The hints are generated being generated ahead of time, taking 95hrs to do so.” — cannonpalms [c:49735109]
（译文：如果你统计信息或者工作负载变了，这套方法就废了。hint 是提前生成的，要花 95 小时。）
Distillation 伦理：OpenAI Astra 轨迹的来源
作者明说做了「off-policy distillation from half a thousand GPT-6 Astra agent trajectories」，devsda 立刻拉出伦理问题：
“I don’t think anybody’s denying that small models are doing distillation, the issue at hand is frontier lab vs frontier lab when it comes to big models.” — Onavo [c:49732382]
（译文：我不觉得有人在否认小模型在做蒸馏，问题在于大模型之间——前沿实验室之间才是问题。）
“Frontier model trainers stole almost all the data they’ve trained on (the whole internet, all copyrighted). It’s very hard for them to claim the moral high ground here. It’s like stealing an apple from the British Colonial Empire.” — make3 [c:49732711]
（译文：前沿模型的训练者几乎所有训练数据都是偷的（整个互联网、所有版权内容）。他们很难说自己站在道德高地上。这就像从大英帝国偷一个苹果。）
篇幅太长
最后一条支线很 HN 风：
“why is this write-up so long? Need 5 days just to go through it.” — coolThingsFirst [c:49732715]
（译文：这篇写得也太长了吧？看完要 5 天。）
“They forgot to run a (same) model to optimize article for reading speed” — tandr [c:49732765]
（译文：他们忘了用同一个模型优化一下文章阅读速度。）
典型观点一览
| 立场 | 用户 | 一句话 |
|---|---|---|
| 警惕 benchmark 偏差 | refibrillator [c:49733010] | 8GB 内存数据集、warmed 缓存、只读 SELECT，离真实 OLTP 远 |
| GPU 加速 Postgres | dragontamer [c:49733880] | 4B 模型跑了 8GB 好几轮，不如认真做 CUDA 加速 |
| LLM 不是对工具 | hamilyon2 [c:49733064] | LLM 是钝刀子，更想等 alphago 风格的神经网络 |
| 小模型就够 | topaz0 [c:49734151] | 这种小而严格的语言映射不需要 LLM，可以做更小的网络 |
| 优化器核心是代价估算 | Sesse__ [c:49737060] | 估准了行数，优化器本来就能找最优 plan |
| 工程风险高 | 2001zhaozhao [c:49733800] | 生产里 hallucinate 漏 index，没法可靠 debug |
| LLM 黑盒可控 | egeozcan [c:49736648] | 加结构化输出 + 校验 + 低温度，可预测性可以接近 100% |
| 黑盒不可验证 | tempfile [c:49738523] | 「跑得快」没法用工具测，LLM 怎么做的都不知道 |
| 训练成本被忽略 | Someone [c:49732105] | 95 小时 + 400 美元 API 不能算进 benchmark |
| 跑过即够用 | hedgehog [c:49732100] | 不放生产，只在测试阶段定位慢 query 就够 |
| Distillation 是行业规则 | make3 [c:49732711] | 前沿模型自己数据也是偷的，没资格指责小模型蒸馏 |
| 优化器本来就难 | malisper [c:49741815] | 即使不用 LLM，验证 plan 跑得快也是数据库未解难题 |
总体情绪
整体偏怀疑，但不是优化派，部分激进。
技术派普遍同意一个判断——优化器是难题，但 LLM 不是这个难题的对工具。4B 模型能做到的事情更像是一个特定的 RL 微调配方碰巧在 IMDb 这种特定数据集上撞到了局部最优，没人相信它能直接复制到 OLTP 场景里。但没人真的在技术上否认实验本身的真实性——数字是诚实的，方法也是诚实的，问题出在「测试集能不能代表真实生产」。
工程派的情绪最务实也最尖刻。生产环境对查询计划有两个核心要求——可调试、可验证。一个 LLM 生成的计划，出了事你没法复现，没法定位，更没法快速修。这种「黑盒上生产」在数据库这种关键基础设施上是不能接受的。
最有意思的暗线是 distillation 的伦理讨论。Astra 智能体轨迹来自 OpenAI GPT-6，小模型蒸馏这件事放在一年前是禁忌，现在变成公理——所有人都默认小模型在做蒸馏。争论的已经不是「该不该做」，而是「大模型自己数据来源是不是干净」。
最后一句话大概是——这是一个诚实的实验，但不是一个智能体评估「数据库优化器需不需要被 LLM 替代」的标准答案。Postgres 优化器几十年来没解决的问题，不是 4B 模型加 95 小时 H100 能解决的。
引用帖子
| # | 标题 | URL |
|---|---|---|
| 1 | Training a 4B model to produce 81% faster query plans than Postgres | https://news.ycombinator.com/item?id=49731285 |