Rohan Bansal trained a 4B model to beat Postgres query plans by 1.81x on 113 join-heavy queries

Rohan Bansal published a write-up on 16 September describing an experiment in which a 4-billion-parameter Qwen model, post-trained with supervised fine-tuning and reinforcement learning, produced Postgres query hints that ran 1.81 times faster than the database's own default plans on the Join Order Benchmark. Bansal says the summed latency across the 113 join-heavy queries dropped by 44.7 percent, and the total training cost was $1,200. The code is released at polyphilz/qorl.

What the model does

Postgres already picks a plan for every query using a cost model that runs in a fraction of a second. Bansal's model sits alongside that planner and writes hints, using the pg_hint_plan extension, which push the planner toward a plan the model has learned tends to run faster. The model was given the query, the schema, and a small set of statistics, and was asked to produce a JSON action that the harness turned into a hint block prepended to the SQL.

The measurements

The benchmark used is the Join Order Benchmark from Leis and colleagues, a public suite of 113 queries across 33 templates over the IMDb dataset. Bansal reports two headline figures: a 1.81x geometric mean speedup per query, taking the best of three rollouts, and a 44.7 percent reduction in summed latency across the whole workload. He notes that the base 4B Qwen model could not produce a valid query plan for 99 of the 113 queries before training, so the reported speedup is measured against Postgres's own default plans, not against the model's untrained output.

Bansal is explicit about the caveats. Measurements were made on his home rig, and the write-up documents a "fooled reward" problem where noisy timing measurements sometimes rewarded plans equivalent to the default. He built a custom scoring variant of GRPO to detect and correct this, and describes how a single-query timing spread can bias a naive median score.

Training setup and cost

Training used off-policy distillation from GPT-6 Astra trajectories for the supervised phase, then reinforcement learning with evaluate_candidate calls that ran the candidate plan and the default plan inside a Postgres container and returned a scalar reward. The RL loop ran across two machines: vLLM and the trainer on a rented 2x H100 node, and four Postgres worker containers on Bansal's desk rig, a pair of RTX 3090s he calls FLOPper. He reports 92 percent of a rollout's time was spent in vLLM inference before he rewrote the loop to lease Postgres workers only when a measurement was needed, which then let him run 20 rollouts concurrently against four workers.

The $1,200 total cost is rented H100 time. Bansal says the run would have been free on his own hardware, at roughly $9 per day of electricity, but he wanted results faster.

The write-up ends with a claim worth reading against your own workload: this pattern only pays back for queries that run repeatedly, because plan-writing at model latency would defeat the point on a one-off. If a team runs the same shape of analytical query over and over, and its cost model already misses on join order, this is a small enough experiment to reproduce end to end and a working reference for what post-training a small open-weights model on a private task actually costs.

Source

• Rohan Bansal, Training a 4B model to produce 81% faster query plans than Postgres, 16 September 2026.
• Hacker News discussion.