Researcher trains 4B model to optimize Postgres queries 81% faster
Rohan Bansal uses reinforcement learning to teach Qwen to beat Postgres's default query plans.
What to know
- A 4B-parameter Qwen model trained via SFT and reinforcement learning achieved 81% faster query execution than Postgres's default optimizer on tested plans.
- Query optimization is a strong fit for LLM learning because performance is easily measurable and verifiable—faster execution is the sole optimization metric.
- Join ordering, a core query optimization task, is NP-hard, explaining why traditional optimizers leave significant room for improvement despite decades of research.
Rohan Bansal Researcher
How it unfolded 1 development · click the chart to see its coverage articlesposts
-
1
Bansal publishes query optimization experiment results
Rohan Bansal published a detailed technical article describing how he trained a 4B-parameter Qwen model to generate Postgres query plans that execute 81% faster than Postgres's default optimizer. The approach combines supervised fine-tuning with agentic reinforcement learning, where each query generates four RL rollouts, with Qwen producing candidate plans that are tested against Postgres for scalar rewards.
“can a small, open-weights model be post-trained via supervised fine-tuning (SFT) and agentic reinforcement learning (RL) to produce Postgres query plans that beat Postgres's default plans?”
— Rohan Bansal -
first by HN Best, 11d ago · also HN Frontpage
-
The end game is adaptive query plans.A big reason the initial plan isn't guaranteed to be optimal, even with all the right indexes, is that table statistics aren't perfect. For example, you might track a column's correlation (how closely the column's logical ordering matches its physical ordering in the heap), but that won't be broken down at a…
2 more of the top 3 · 19 posts in this stretch
-
I had the similar feelings, the setup is biased for certain outcomes it feels. At times I feel like that I am in an eternal questioning mode but then again I find it to be a better choice to be critical and skeptical for technology related things.Couple things that I found interesting1. Inefficiencies/limitations of the query planner in certain…
-
> I paid ~$800 to rent a 2x H100 SXM node from Lambda for ~95 hours, and ~$400 in OpenAI API fees to generate the Astra trajectory demonstrations.> a tiny 4B model went from not being able to understand the harness it was wrapped in, to achieving a 1.81x geometric mean speedup and a summed latency decrease of 44.7% across a workload of join-heavy…
-
What people are saying 16 voices from 1 site · best of 19 · verbatim
- Sep 18
-
> The goal isn’t to try and beat Postgres on the time/efficiency Pareto frontier for one-off queries, but we may be able to beat it on queries that run over and over again.This is the most important part. Most queries are either quick transactions that can run thousands of times per second, or complex but predictable scheduled analytics.One off…
-
Neat. Can this model learn which table indexes to create that would improve performance? In my experience, nested loops will be chosen in a query plan over poorly chosen indexes, but well chosen indexes will result in drastic speed ups.
- Sep 17
-
I am skeptical of these results given that the end has:> Favorite settings The model regularly used enable_sort=off and random_page_cost=1.1If random_page_cost wasn't set correctly for the default cases postgres's query planner can generate terrible plans (unless you're running on a spinning disk).That could easily explain the difference by itself.
-
It's certainly a good idea to train a neural network to find good query plans but... an LLM??
- Sep 16
-
I think in principle you could clone your database in prod and at least test to see if your most difficult + common queries are indeed faster after running through the LLM optimizer?
-
I have a theory that soon enough every code library will ship a CLI and a very tiny finetune for that specific lib alongside it
-
An 8GB dataset? That’s literally a few seconds worth of records generated in my world, and any speedup at that scale is completely meaningless.Let’s talk when you are looking at double digit TB at a minimum.
-
Suppose you run a platform, and you run a couple thousand different queries of different types throughout the day. It would make sense to have an auto-optimizer that would read long queries, ponder over them with an LLM, come up with some good plans, and store them as hints. This seems like quite a good idea? Is there a product for this?
-
Unless they’ve been elided, there were no indices other than the PK on any table, and no additional statistics. There are correlated columns here: a given country may have produced more movies in a given range of years, as its movie industry built up; a given country may produce more TV series than movies, etc.Nearly every time I’ve seen someone…
-
81%is nothing. It is not hard to be more than 3x better than Postgres [1]. And you don’t need a model to do that, let alone a 4B model. How much additional compute is needed to just run that model?[1]
-
This was a thoroughly enjoyable read, both the writing and presentation. I really liked the level of writing as it's basically introducing a whole lot of advanced topics but at just the right level for a non-AI researcher type of engineer like myself to be able to understand what's going on, and I felt it made some elements of LLMs actually…
-
With a 4B parameter model that probably ran through 8GBs of RAM multiple times to run.At a certain point we should seriously talk about CUDA accelerating Postgres instead.
-
Engineer: "HELP, our production DB is frozen on this query that worked fine before!"Infra: "Hmm, let's check... Well would you look at that, it seems like your LLM query planner usually works and produces fast queries, but this time when you changed a variable name to trigger query rebuild, it happened to hallucinate and miss an index, would you…
-
Optimal plan construction is math-heavy, algorithm-heavy and vary even by workload. There are options like creating just-in-time indexes, so solution space grows even faster than article presents. Sometimes it is the query planner which is the slow part of total execution time.LLM is kind of blunt weapon to use here. I am waiting rather for…
-
“81% faster query plans than Postgres”…on an 8 GB dataset that fits entirely in memory, with shared_buffers constrained to a fraction of that, queries warmed before measuring, and read-only SELECTs.I would be cautious about over fitting, it’s tough to say if those query plans would really be more optimal than Postgres heuristics at scale and with…
-
> Frontier intelligence is extremely powerful; the distillation I did off Astra trajectories is proof enough that large models are not going anywhereWouldn't admitting this invite trouble due to accusations of distillation flying around between closed and open models.