A 4B Model Just Beat Postgres at Its Own Planner

A 4B model now builds query plans 81% faster than Postgres itself. The weakness it exploits: your planner guesses row counts. Badly.

Dafallah Ibrahim

— 2 min read
Share

Somewhere between "neat demo" and "existential threat to DBAs," someone trained a 4-billion-parameter model to produce query plans that run 81% faster than the ones Postgres's own planner picks. The interesting part isn't the model. It's what the result admits: Postgres's planner has been guessing this whole time.

The model isn't outsmarting the database. It's exploiting a weakness every cost-based optimizer has shipped with for decades — and that weakness is costing you latency today, no AI required.

Why this matters

Every plan decision — join order, hash join versus nested loop, sort versus index scan — flows from one number: how many rows the planner thinks each step returns. When that estimate is off by 10x at one join, it's off by 1000x three joins later, because errors multiply.

You've seen the symptom: rows=1 in the plan, actual rows=4,000,000 in EXPLAIN ANALYZE, and a nested loop grinding through all of them. The planner isn't buggy. It's executing flawlessly on bad information.

How it works

Postgres keeps statistics per column: most common values, a histogram, a distinct-count estimate. Two problems. First, it's a sample — tens of thousands of rows, from tables that may hold billions. Second, the stats are per column. Filter on two columns and the planner assumes they're independent, so it multiplies the two selectivities.

Real data is never independent. country = 'DE' and city = 'Munich' are nearly one predicate. deleted_at IS NULL correlates with everything. Stack enough broken independence assumptions and your cardinality estimate is fiction. A learned planner trains on actual execution outcomes, so it captures joint distributions a per-column histogram cannot represent. The 81% isn't faster execution — it's the absence of catastrophic plan choices.

Where this helps

  • Analytics with many joins. Five-table dashboard queries where each misestimate compounds into a serial nested loop.
  • Skewed multi-tenant tables. One tenant is 40% of the rows; the planner plans for the average tenant.
  • ORM-generated queries. Parameterized statements flip to generic plans that fit no actual bind values.
  • Nightly ETL. One bad plan turns a 20-minute job into a 6-hour job, and it only fails on month-end volumes.

Watch out

That 81% is on their workload. Learned optimizers have always struggled to generalize — your schema and your pathological query weren't in the training set. A 4B model also adds inference time to planning, which sub-millisecond OLTP budgets won't absorb. And you'd need guardrails, because a confidently wrong learned plan with no fallback is worse than a mediocre heuristic.

The good news: you can claw back a chunk of that 81% with tools Postgres already ships.

Try it yourself

Catch the planner lying, then teach it about your correlated columns:

-- Find the lie: compare estimated vs. actual rows
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM orders
WHERE country = 'DE' AND status = 'pending';

-- Estimated rows=1, actual rows=812000?
-- The independence assumption just broke on you.

-- Teach Postgres these columns are correlated:
CREATE STATISTICS country_status (dependencies, mcv)
  ON country, status FROM orders;
ANALYZE orders;

-- Re-run the EXPLAIN. Watch the estimate snap
-- toward reality and the plan shape change.

TL;DR

  • What changed: a 4B model trained to emit query plans beat Postgres's planner by 81% on its workload.
  • Why it matters: cardinality — the planner's core input — is a guess built on per-column stats and an independence assumption your data violates.
  • Try today: run EXPLAIN ANALYZE on your worst query, find where estimated diverges from actual, and add CREATE STATISTICS on the correlated columns.

Read more