EXPLAIN Yourself! Finding Query Planner Stalls Across DBMSes

2026-08-24Databases

Databases
AI summary

The authors studied how quickly database systems make plans to run queries and found that this planning step can sometimes take a very long time, over three minutes for certain queries. This means that planning isn’t always a quick, cheap step as often assumed, and slow planning can cause problems like wasting database resources or even causing service disruptions. They examined seven different database systems and found some common tricky query patterns that cause slow planning, such as complex subqueries and joins. The authors also provided these problematic queries to help others test and improve query planners.

query plannerDBMSquery optimizationsubqueryCTE (Common Table Expression)query execution plandisjunctive joinconstant foldingdenial-of-servicequery latency
Authors
Geoffrey X. Yu, Ryan Marcus, Tim Kraska
Abstract
Query planners are typically expected to produce optimized plans quickly, leading many researchers (including the authors of this paper) and practitioners to design systems that assume query planning is a low-cost operation. Using a lightweight agentic search, we show that this assumption does not always hold. Across seven DBMSes, including four commercial systems, we find at least one query per system that takes more than three minutes to plan. In addition to being slow to plan, such queries risk tying up database resources without performing useful work, creating a potential denial-of-service vector. We analyze the queries our search uncovers and compare how the seven systems respond to each pattern. We find that although the queries triggering slow planning are largely DBMS-specific, recurring pathologies involving correlated subqueries, CTE expansion, repeated subquery expressions, disjunctive joins, and constant folding affect multiple systems. We release our uncovered queries along with a curated suite of parameterized query pathologies that researchers and database engineers can use to test planner robustness. Overall, our results show that query planning cannot always be treated as a predictably inexpensive operation and that its latency and robustness deserve further attention from both database researchers and engineers.