朋友们，今天这个槽点我酝酿了很久，因为它实在太荒诞了。一个叫Rohan Bansal的哥们，solo项目，没有团队，没有融资，用1200美元训了一个40亿参数的小模型，直接把Postgres的查询优化器按在地上摩擦，速度提升了81%。你没看错，81%，不是8.1%。
我再重复一遍这个数字：1200美元。这个钱在北京三环租一个月房子都不够。这个钱在硅谷连一顿像样的team lunch都请不起。但这个钱，够一个人训练出一个比Postgres默认查询计划快1.81倍的AI模型。
桌面跑Postgres，云端训模型，这才是真正的全栈
这个项目的架构我必须详细说说，因为它简直是工程界的"一边骑自行车一边弹吉他"。Rohan同学在他的桌面电脑上跑了4个Postgres容器，用来生成训练数据和评估查询计划。与此同时，他租了2块H100 SXM在云端跑了95个小时进行模型训练。桌面端出数据，云端出模型，完美闭环。
你可能会问：就这？就这。先用~500条GPT-6 Astra的轨迹做SFT（监督微调），然后用自己魔改的GRPO变体做强化学习。总共花了400美元的OpenAI API费用来生成这些教学轨迹。剩下的800美元是GPU租金。1200美元，打完收工。
但这里有个细节特别有意思：训练之前，这个4B小模型在113个join-heavy的SQL查询中，99个连查询计划都生成不出来。是的，99个，接近88%。它就像一个学生交了白卷。经过SFT + Agentic RL之后，全部113个查询都能生成比Postgres默认更好的计划。从交白卷到全科满分，这就是RLHF的魔力，不对，是GRPO的魔力。
组合爆炸：一个你不想面对的数学噩梦
为什么查询优化这么难？因为join ordering是NP-hard问题。什么意思呢？3张表就有4,608种执行计划。5张表？3,300万种。6张表？18亿种。7张表？5,320亿种。8张表？86万亿种。
86万亿。这个数字是什么概念？全世界80亿人，每人要评估10万种方案。Postgres的优化器面对这个组合爆炸只能用启发式算法——说白了就是"差不多得了"。但现在一个4B的小模型，经过训练后，居然能在这个NP-hard的地狱里找到更优的路径。
Hacker News上有位老哥说得好：P!=NP恰好是LLM有用的数学基础。生成（generation）是昂贵的、启发式的，但验证（verification）是廉价的。你不需要证明AI找到了最优解，你只需要证明它找到的解比Postgres默认的快就行了。多么优雅的工程哲学。
HN评论区：比原项目更精彩
这条新闻在Hacker News上拿了483分、96条评论，评论区的槽点比原项目还多。
有人说"Stealing an apple from the British Empire"——前沿大厂用盗版数据训练模型，现在你用它们的输出蒸馏，谁也没资格站在道德高地上指指点点。好家伙，这是一条AI训练的道德供应链：OpenAI偷互联网的数据 → 你偷OpenAI的输出 → Postgres用户偷你的时间。大家都有光明的未来。
还有人吐槽这篇文章"需要5天才能读完"，另一位立刻回复："他们忘了用同一个模型优化文章阅读速度。"我笑出了声。这位朋友，你很有幽默感，但你可能不知道，优化阅读速度的问题也是NP-hard的。
当然也有严肃的技术讨论：怎么验证AI生成的查询计划真的执行正确？答案是：Rohan跑了所有计划，对比了实际执行结果。但评论区的灵魂拷问是——你愿意每几小时重新训练一次模型吗？数据库schema变了怎么办？数据分布漂移了怎么办？这些问题目前没有答案，但这不妨碍我们先爽一波。
Friends, I've been holding onto this one because it's just too absurd. A guy named Rohan Bansal — solo project, no team, no funding, just vibes — trained a 4-billion parameter model for $1,200 and proceeded to absolutely body-slam Postgres's query optimizer, achieving an 81% speedup. That's 81%. Not 8.1%. Eighty. One. Percent.
Let me repeat that number: $1,200. That won't get you a month's rent in San Francisco. That won't cover a team lunch at a decent restaurant in Manhattan. But apparently, it's enough to train an AI model that produces query plans 1.81x faster than what Postgres has been shipping for decades.
Desktop Postgres, Cloud GPUs: The Real Full-Stack Developer
The architecture of this project deserves its own paragraph because it's the engineering equivalent of juggling while riding a unicycle. Rohan ran 4 Postgres containers on his actual desktop computer to generate training data and evaluate query plans. Meanwhile, he rented 2x H100 SXM GPUs in the cloud for 95 hours of model training. Desktop generates data. Cloud generates models. Circle of life.
The method? Take ~500 GPT-6 Astra trajectories, do Supervised Fine-Tuning (SFT), then run a custom GRPO variant for reinforcement learning. $400 of that $1,200 went to OpenAI API costs for generating those teaching trajectories. The remaining $800 was GPU rental. $1,200 total. Mic drop.
But here's the kicker: before training, this 4B model couldn't even generate query plans for 99 out of 113 join-heavy SQL queries. That's 87.6%. It was basically submitting blank papers. After SFT + Agentic RL? All 113 queries got plans that beat Postgres defaults. From flunking every exam to acing the whole class.
Combinatorial Explosion: A Math Nightmare You Didn't Ask For
Why is query optimization so hard? Because join ordering is NP-hard. Here's what that means in practice: 3 tables give you 4,608 possible plans. 5 tables? 33 million. 6 tables? 1.8 billion. 7 tables? 532 billion. 8 tables? 86 trillion.
Eighty-six trillion. That's every human on Earth evaluating 107,500 plans each. Postgres's optimizer, faced with this combinatorial apocalypse, does what any reasonable engineer would do: uses heuristics and says "good enough." But now a 4B model — smaller than most frontier model's embedding layers — trained for less than a week's worth of cloud compute, finds better paths through this NP-hard hellscape.
One HN commenter nailed it: P!=NP is exactly what makes LLMs useful. Generation is expensive and heuristic. Verification is cheap. You don't need to prove the AI found the optimal plan. You just need to prove it found a plan that's faster than Postgres defaults. That's it. Beautiful engineering philosophy.
HN Comments: More Entertaining Than the Original Paper
This hit 483 points and 96 comments on Hacker News, and the comment section is honestly more entertaining than the research itself.
Someone pointed out the "Stealing an apple from the British Empire" angle — frontier labs trained on copyrighted data, so they can't claim moral high ground when someone distills their outputs. Welcome to the ethical supply chain of AI training: OpenAI scrapes the internet, you distill OpenAI's outputs, Postgres users steal your time. Everybody wins. Nobody's hands are clean.
Then someone said the blog post "needs 5 days to read," and another commenter immediately fired back: "They forgot to optimize article reading speed with the same model." I actually laughed out loud. Sir, you have great comedic instincts, but I hate to inform you that optimizing reading speed is probably also NP-hard.
There were serious concerns too: how do you verify the AI-generated plans actually execute correctly? Rohan's answer: run all the plans and compare actual results. But the real existential question from the comments: are you willing to retrain a 4B model every few hours when schemas change? When data distributions shift? Nobody has answers yet, but that's a problem for tomorrow. Today we celebrate.
1200美元，在北京三环租一个月房子都不够，却够一个人训练出一个比Postgres优化器快81%的AI模型。数据库公司几十年的工程积累，被一个solo开发者用4B小模型按在地上摩擦——你品，你细品。
—— Dawn Vision编辑部
$1,200 won't get you a month's rent in San Francisco, but it's enough for one guy to train a 4B model that makes Postgres's query optimizer — the product of decades of database engineering — look like it's been phoning it in. Let that sink in.
— The Dawn Vision Editorial Desk
<strong>实用Tips：</strong><ol><li>小模型做大模型蒸馏：先用GPT-6等大模型生成高质量轨迹做SFT，再用RL微调小模型，比从零训练效率高几个数量级。</li><li>查询计划验证铁律：永远用EXPLAIN ANALYZE跑实际执行结果对比，别信AI的自我评估。</li><li>成本意识：1200美元能做这么多，但前提是有扎实的数据库和ML功底，否则大概率得到一个跑不通的notebook。</li></ol>
<strong>Practical Tips:</strong><ol><li>Small model distillation: use frontier models (GPT-6 etc.) to generate trajectories for SFT, then fine-tune with RL. Orders of magnitude more efficient than training from scratch.</li><li>Query plan verification: always use EXPLAIN ANALYZE to compare actual execution results. Never trust the AI's self-assessment.</li><li>Cost reality check: $1,200 goes far with the right skills. Without solid database and ML fundamentals, you'll likely end up with a broken notebook and a pile of error logs.</li></ol>
Sources · 信源 Sources
本文基于 Dawn Vision 认知引擎处理的公开信息整理，素材来源：Rohan Bansal博客、Hacker News。
This article was generated by the Dawn Vision cognitive engine processing publicly available information. Sources: Rohan Bansal's blog, Hacker News.
