Reduce high planning time on complex queries
A fourteen-relation star join spent 378.737 ms planning. Capping join_collapse_limit at 6 brought planning down to 2.044 ms and produced exactly the same plan.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
The planner searches join orders exhaustively, and the search space grows factorially with the number of relations. Past a dozen or so tables the planning itself becomes the expensive part. Nothing in EXPLAIN ANALYZE's execution numbers hints at it, you have to look at Planning Time, which most people skip straight past.
A Meridian reporting query joins route_legs to thirteen dimension tables. Execution is fine. The endpoint is still slow, and the slowness scales with nothing anyone can measure in the data.
Simple terms
Before it runs a query, the planner tries different orders to join the tables and keeps the cheapest. The number of possible orders explodes as you add tables, so past a dozen or so the planning step itself becomes the slow part, and it hides in Planning Time, the line most people scroll straight past in EXPLAIN. Capping join_collapse_limit tells the planner to stop exploring so many orders; on a big star join it often lands on the same plan in a fraction of the time.
Full runbook for this incident
- The full identify checklist, the exact signals that tell you it's this incident
- Every diagnostic query; lab output is attached only to the steps we actually captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
Card required. Cancel before day 7 and you are not charged.
More in this category
Other Query performance runbooks
Neighbouring incidents that share the same diagnostic surface.
Need the full procedure?
Pro runbooks finish the incident path
Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.