Query Optimization on lqo.net

First LQO Release Finds the PostgreSQL Queries a Planner Setting Makes Faster

Mon, 19 Oct 2026 00:00:00 +0000

Every PostgreSQL database has a few queries the planner gets badly wrong. Not slow because they’re big. Slow because the planner guessed the wrong row count, picked a plan for ten rows, and got ten thousand. Finding them is usually an afternoon with EXPLAIN ANALYZE, one query at a time.

LQO 0.1 does that afternoon for a whole workload. Give it a server log or a file of queries, point it at a replica, and it runs each kind of query under PostgreSQL’s default plan and under a set of planner settings. Then it tells you which settings make which queries clearly faster, with the exact lines to use.

LQO Finds Faster PostgreSQL Plans for 35 of 94 Join Order Benchmark Query Shapes

Mon, 19 Oct 2026 00:00:00 +0000

The Join Order Benchmark is where query optimizers go to be embarrassed. It’s 113 queries over the IMDB movie database, real data with all its skew and correlated columns, and it was built to show how far a planner’s row estimates can drift from the truth. If a tool claims to find better plans, this is the first place anyone should look.

So LQO 0.1.0 ran it, start to finish, on a GitHub runner: 4 cores, 15 GB of memory, PostgreSQL 16 with 5 GB of shared buffers. The 113 queries fold into 94 query shapes, because some JOB variants differ only in their constants. Each shape ran under the default plan and under LQO’s 13 standard hints, with a warm-up run and three timed runs per plan. The whole thing took 75 minutes.

How LQO Was Tested, From Writes It Must Never Run to Traps It Must Find

Sun, 18 Oct 2026 00:00:00 +0000

A tool that runs your queries on a database has two jobs, and the first one matters more. It must never do harm: no writes, no settings left behind, no runaway query. Then it must actually find something. LQO’s tests go after both, against a real PostgreSQL server rather than a mock.

All 62 tests pass in the recorded run, on a two-core cloud machine with PostgreSQL 16. CI runs them again on every change against PostgreSQL 14 and 18, and runs the parts that need no server on macOS and Windows. The logs are on GitHub.

What Is a Learned Query Optimizer? Why PostgreSQL Picks Slow Plans and How to Steer It

Sun, 18 Oct 2026 00:00:00 +0000

A query optimizer turns your SQL into a plan: which table to read first, which index to use, how to join one table to the next. A learned query optimizer is one that improves its choices from what actually happened when queries ran, instead of trusting its own predictions. The idea is older than it sounds, and it’s finally practical.

To see why it matters, look at how an ordinary optimizer goes wrong.