Why LQO Stands for Learned Query Optimizer, and What It Learns

LQO is short for learned query optimizer, the name database researchers use for an optimizer that improves from what queries actually did rather than from its own predictions. Say it as three letters, L-Q-O. The name is plain on purpose. It says what the thing is to the people most likely to look for it.

Each word does some work, though, and one of them needs an honest footnote.

Query Optimizer

Every SQL database has an optimizer. It’s the part that decides how to run your query: which table first, which index, which way to join. You don’t see it, but it’s the reason the same SQL can take 4 ms or 4 seconds. PostgreSQL’s optimizer is the planner, and LQO works with it rather than around it.

Learned

This is the word with the footnote. In research, “learned” usually means machine learning: neural networks trained on thousands of plans, deciding how to join tables. Some of those systems are remarkable. They’re also hard to explain, slow to train, and now and then they pick a plan that’s far worse than the one they replaced.

LQO version 0.1 learns in the oldest sense of the word: by trying. For each kind of query, it runs the default plan and the alternatives on your data, measures them, and keeps what was clearly and consistently faster. Every suggestion comes with the timings that earned it. There’s no model to trust, only a rule and a log.

That’s a choice, not a shortcut. A database team can check a measurement. It can’t check a neural network’s hunch. And the research that made learned optimizers practical, the Bao work from MIT in 2021, showed the biggest wins come from steering the existing optimizer with its own switches, which is exactly what LQO does.

Optimizer, Not Replacement

LQO never writes a plan of its own. It only flips PostgreSQL’s own planner switches, such as enable_nestloop, and lets PostgreSQL do the planning. So it’s an optimizer for your optimizer: it learns where the planner’s guesses fail on your data, and nudges it there and nowhere else.

The explainer on learned query optimizers has the longer story, from IBM’s DB2 in 2001 to the systems running inside Microsoft, Databricks and Alibaba today.