$1,200, 95 Hours, One 4B Model: Re-teaching Postgres Query Planning

Forum topic · QianXun · 2026-09-18

Summary

An independent project by engineer Rohan Bansal trained a 4B-parameter model (Qwen3.8-4B distilled) to generate pg_hint_plan hints that speed up Postgres query plans by up to 81% (geometric mean) on the JOIN Order Benchmark. The pipeline distills 420 GPT-6 Astra trajectories via SFT + LoRA, then applies anchored GRPO reinforcement learning using EXPLAIN ANALYZE latency as a free reward signal, keeping SQL unchanged and correctness guaranteed by the database itself. Total cost: roughly $1,200 (95 hours on two Lambda H100s plus $400 in teacher API fees), with measurements on a home machine running 4 Postgres containers over Tailscale, 20 runs per config taking medians. Caveats matter: single-shot use yields 1.40x, the baseline may lack secondary indexes, and inference time is excluded. The post argues the real insight is the paradigm: models only produce hints checked into git, with no model on the hot path — and that any domain with a free, automatic reward signal is a candidate for similar small-budget RL experiments.

It's 2 a.m. and a query has been running for four minutes. You open EXPLAIN and the join order in the plan tree is clearly wrong — stale statistics, or a cost formula that just doesn't fit this batch of data. Hand-write a hint, and four minutes becomes four seconds. The database didn't change, the data didn't change; only "which path to take" did.

Behind that door lies a problem the database industry has argued about for over thirty years: who should decide the query plan?

On September 16, a Hacker News post gathered 381 upvotes with a blunt title: training a 4B model to produce query plans 81% faster than Postgres. The author is Rohan Bansal, a former Google, Traba, and Crosby engineer, working on it during a Recurse Center break. No company, no funding — the code is open-sourced on GitHub as qorl.

What he did in one sentence: take a 4-billion-parameter open-source model and teach it to write execution hints for Postgres.

The Pipeline

Base model: the open-source Qwen3.8-4B distilled edition — nominally 4B, actually 4.66B parameters.
Teaching material: 420 trajectories generated by GPT-6 Astra — a large model sketches, a small model learns.
Training: distillation (SFT + LoRA) first, then reinforcement learning (anchored GRPO).
Reward signal: refreshingly simple. The hint is fed to pg_hint_plan, Postgres actually runs EXPLAIN ANALYZE — fast is fast, slow is slow.
Correctness: the SQL is never modified; the database itself guarantees correctness end to end.

The Exam

Training used CEB (13,600 IMDb queries); the exam was the JOB benchmark — 113 queries from Leis et al.'s famous 2015 paper — on the same 8.5GB IMDb database. The author states plainly in the blog: this is about learning *this one database*.

Scorecard: under a pick-1-of-15 protocol, the geometric mean speedup is 1.81x — that's the "81%" in the headline. Total workload latency dropped 44.7%. Of the 113 queries, 68 got more than 5% faster; 0 regressed.

The Bill

Two H100s rented on Lambda for 95 hours: ~$800
Teacher-trajectory API costs: ~$400
Total: a bit over $1,200

The infrastructure is a hybrid: training in the cloud, measurement on the author's home machine (nicknamed FLOPper) running 4 Postgres containers, connected back to cloud rollout workers via Tailscale at 20-way concurrency. Measurement discipline: warm up each configuration, then take the median of 20 runs.

The Fine Print

1. The 1.81x assumes "run 15 times, pick the best" — selection based on a pre-evaluation pass. No production database gives you 15 attempts. Single-shot use drops the speedup to 1.40x. The ablation table lays it out: distillation alone gets 1.16x; full RL at 1,200 steps reaches 1.41x. The model's improvement is real — but the headline gain leans on the selection protocol.

2. Model inference time isn't counted in the comparison, and training costs aren't part of the runtime story. "Plans execute 81% faster" and "the planner is 81% faster" are two different ledgers.

3. The baseline itself is suspect. HN commenters found that the test tables appear to have only primary-key indexes — Postgres is fighting with one hand tied. The 8.5GB dataset sits fully in warm cache, read-only, single database. No comparison against lightweight specialized tuners like Bao either; the author admits that's next on the list.

Bonus from the fine print: the author invented a metric called *fooling rate* to quantify measurement noise. A no-op plan — one that changes nothing — was "measured" as 10–26% faster two to three times out of ten. Bumping the cache from 128MB to 2GB only reduced the error rate fourfold. If you do performance comparisons, this should send a chill down your spine: have you measured whether *your* comparisons contain phantoms?

Is It Still Worth Watching? Yes.

The real point is the paradigm. The model appears exactly once, during development. Its entire output is a few lines of SQL comments that go into git and ship with the release. No model sits on the database's hot path, no new failure surface. When workload drift invalidates the hints — a pitfall the author honestly documents — you retrain.

Deeper still: those $1,200. RL is expensive because rewards are hard to define. Here the reward is free: run EXPLAIN ANALYZE and speed speaks for itself. Wherever there's a free referee, a small model plus a small budget can deliver. The lessons transfer: compiler IRs, cache eviction policies, scheduler parameters — any corner with cheap automatic scoring could be the next $1,200 experiment.

Postgres's planner descends from System R — a 1979 skeleton still on duty, guessing paths from statistics and cost formulas. When it guesses wrong, the fix has always been hand-written hints. Now there's another option: let a 4B model write those comment lines for you, tuition $1,200 a run.

How many corners of your system are hiding a free referee that nobody ever thought to ask?

--- Sources: author blog rohanbansal.com/qorl (2026-09-16); HN discussion 49731285; code github.com/polyphilz/qorl; JOB benchmark from Leis et al. 2015.