让 4B 小模型给 Postgres 挑执行计划：最好的候选快 81%，代价是同一个查询要试 15 次
给 Postgres 挑执行计划一直是数据库自己的活，现在有人用 4B 小模型把这件活得更好：在 113 条 join 密集的 JOB 查询上，从多个候选里挑最好的一条，几何平均提速 1.81 倍，整批查询总耗时下降 44.7%。

底座是德国小实验室 Empero 蒸馏出的 Qwen3.8 4B，作者先让模型学会 agent harness 的输出格式，再用 GPT-6 Astra 跑出的轨迹做离线蒸馏，最后用改造过的 GRPO 做强化学习——奖励直接取 Postgres 实测的执行时间。为了不被测量噪声骗到，他把 Postgres 的 shared_buffers 从 128MB 调到 2GB，no-op 误判率降了约 4 倍，每个候选跑三次取中位数，差异在 5% 以内算平局。

那个 81% 有个必须说清的条件：它是 best-of-15——同一个查询跑三次，每次最多出 5 个候选，再挑最好的一条；如果每个查询只跑一次，模型的成绩是 1.16 倍。评测只在 JOB 这一个基准上做，用的是作者自己桌上四个 Postgres 容器，没有上生产，也没测并发和写负载。代码在 polyphilz/qorl 开源。

我的判断：这条消息的价值不在那个数字，而在方法——用可验证的执行时间当奖励做 Agentic 强化学习，在数据库这种"答案便宜、执行结果可测"的场景里已经跑通。想跟进的人先复现它的测量装置，别急着换优化器：样本只有 113 条查询，换个数据分布结果就可能变。