Fifteen is the number behind the 81% speedup headline. For each query, QORL let a 4-billion-parameter model sample as many as 15 candidate plans, timed them against PostgreSQL, and kept the best result. That measured search produced a 1.81x speedup on a 113-query benchmark, according to researcher Rohan Bansal's technical report.
The same report gives the result in less slippery terms: summed query latency fell 44.7%. A 1.81x speedup means the workload took about 55.3% of PostgreSQL's default time. The run covered join-heavy analytical queries from the Join Order Benchmark, or JOB, rather than a general sample of database work.
That narrow boundary is the point of the experiment. QORL is a worked example of a small model learning to operate a measurement harness around a mature system. The released repository describes it as a research harness that steers PostgreSQL toward faster physical plans. PostgreSQL still parses and executes every query.
The speedup came from measured search
Bansal's final checkpoint followed 1,200 reinforcement-learning updates. In the strongest evaluation, the model ran three trajectories for each JOB query and could propose five candidates per trajectory. A fixed selection rule chose the candidate with the best preliminary timing when it cleared a 1.05x threshold. Otherwise, it retained PostgreSQL's default. Across all 113 queries, that best-of-15 procedure recorded 68 wins and no regressions in the published results.
The lower-effort rows in the evaluation table tell a different story. Taking the model's own selection from each single trajectory produced a 1.40x geometric-mean speedup and a 1.24x total-workload speedup, with seven regressions among 339 trajectories. Choosing the best measured feedback inside each five-candidate trajectory improved those figures to 1.44x and 1.29x. Repeating the search three times, then comparing up to 15 candidates, is what moved both metrics to 1.81x.
Those metrics answer separate questions. The geometric mean gives every query equal weight, so one huge win cannot conceal many slowdowns. Total-workload speedup adds all default runtimes and divides them by all candidate runtimes, which better reflects the time saved across a batch. Both landed at 1.81x in the best-of-15 run, a coincidence Bansal calls out in the results. The matching values say the gain was visible across queries and in total elapsed work.
The headline result therefore includes two safety rails: repeated execution and a known-good default. This pattern suits recurring analytical queries because the cost of testing candidates can be paid once and recovered over later runs. Bansal scopes the idea to queries executed thousands of times, where tens or hundreds of exploratory executions may be amortized. A one-off query has no such repayment window.
Measurement took more work than asking PostgreSQL for one timing. Bansal found that cache state could split repeated executions of the same query into fast and slow clusters. His final evaluation used interleaved candidate and default runs, with three pairs after a candidate was selected, then compared medians. The measurement section describes four fixed-resource PostgreSQL containers. Raising shared_buffers from 128 MB to 2 GB cut the measured no-op error rate from about 5% to between 1.2% and 1.8%. Without that tuning, timing noise could become the reward and teach the model the wrong lesson.
PostgreSQL leaves room for an offline tuner
A SQL statement describes the answer, while the query planner chooses how to obtain it. With several joined tables, it must consider join order, join algorithm, scan type, parallel work, and other settings. The space grows too quickly for exhaustive search on large joins. PostgreSQL's current documentation says its genetic query optimizer uses a non-exhaustive search for complex queries, with a default trigger of 12 FROM items. That saves planning time at the risk of an inferior plan, as the PostgreSQL query-planning guide explains.
JOB exists to test this difficult corner. Its authors introduced 113 multi-join queries over a real IMDb dataset and found that cardinality estimators routinely made large errors. Their 2015 VLDB paper also found that exhaustive enumeration could improve execution despite imperfect estimates. QORL reuses those 113 queries for evaluation and trains on 13,646 queries from a separate Cardinality Estimation Benchmark. Bansal checked the join-graph topologies and reported no overlap between the training and test templates.
QORL steers plans through pg_hint_plan, an extension that accepts structured hints in SQL comments. The agent can inspect relation metadata, request column statistics, view PostgreSQL's default plan, submit a candidate for validation and timing, or keep the default. Its output becomes a constrained plan action that the harness compiles into hints. The model searches over execution choices rather than writing application SQL and sending unchecked code to a production database.
The model first had to learn the tools
The base was empero-ai/Qwen3.8-4B-Distill, a 4.66-billion-parameter model distilled from a much larger Qwen teacher. Before training, it struggled with the harness itself. On the 113 JOB queries, 81 runs produced no valid candidate, 16 failed during selection, and one timed out. Only 15 trajectories contributed to its score, which landed at 0.85x PostgreSQL's default in the baseline table.
Bansal used supervised fine-tuning to teach tool use from GPT-6 Astra trajectories, then applied reinforcement learning against measured query times. A low-rank adapter kept the trainable portion small: 21.2 million parameters in a 42.5 MB LoRA, compared with 9.32 GB for the base model in bf16. The public QORL code includes the JOB and CEB task inventories, experiment configurations, PostgreSQL worker setup, and tests needed to inspect the machinery.
The reward design failed before it worked. An early penalty for invalid plans was so harsh that the model repeatedly chose PostgreSQL's default. Plain group-relative scoring then rewarded plans that were merely less bad than their siblings, even when none beat the default. Bansal changed the reward calculation to anchor quality against PostgreSQL, assign no positive credit within 5% of the baseline, and penalize duplicate or invalid outputs. After 120 updates, the first reinforcement-learning checkpoint was still worse than its supervised starting point. The gains appeared over two longer runs totaling 1,200 updates.
The final traces show behavior a database engineer can recognize. Of 337 searches that submitted a candidate, 295 first inspected a relation, column statistics, or the default plan. Across 1,347 actions, the model issued 1,141 scan hints and 917 join-order hints. The trace analysis attributes much of the gain to rewritten join orders, a single scan change, or parallel execution. Those are specific planner interventions.
A narrow result with a practical lesson
The experiment trained and tested against the same IMDb database, while holding out query topologies. Bansal argues in the benchmark discussion that database specificity is intentional because a company would tune a recurring workload against its own data. It also limits the claim. The report does not establish that the adapter transfers to another schema, survives a large change in data distribution, or improves transactional queries. Public code makes those questions testable, but it does not answer them.
Cost also belongs in the comparison. Bansal's accounting puts the rental for two H100 SXM GPUs at about $800 for roughly 95 hours, plus about $400 in API calls for teacher trajectories. His local system, built around two RTX 3090 GPUs, handled database measurements while the rented node ran inference and training. The total was $1,200, before counting local electricity. PostgreSQL's built-in planner arrives with the database and needs no model-training budget.
For developers, the reusable idea is the loop around the model. QORL gives it bounded actions, checks each candidate, measures the outcome, and preserves a trusted fallback. The database's execution time supplies an objective score. Tasks with an equally cheap verifier and a stable workload may suit the same approach. Tasks judged by taste, delayed business outcomes, or unsafe trial execution lack this clean signal. The released harness makes that loop inspectable instead of hiding it behind a benchmark number.
Independent reproduction is the next useful test. In the report, Bansal proposes measurements on dedicated cloud hardware and a comparison with structured hint sweeping. A stronger result would retain the gains on a fresh database or after its data shifts, while also counting the time spent sampling candidates. Until those tests land, QORL is evidence for measured search on repeated queries. PostgreSQL's general-purpose planner still has the wider job.