Refresh stale statistics that break query plans
After a bulk load the planner's stats lag reality, so it estimates 1 row where there are ~100 and picks the wrong plan. A single ANALYZE restores accurate estimates.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
The planner relies on column statistics gathered by ANALYZE/autovacuum. Right after a large load or a data-shape change those stats are stale, the estimates are wrong, and the planner makes decisions on numbers that no longer hold.
Meridian bulk-loads courier_shifts and immediately queries by courier_id. Autovacuum has not caught up, so the planner still thinks the filter matches 1 row when it really matches ~100, and plans accordingly.
Simple terms
The planner makes its choices from a saved summary of each column, how many distinct values there are and how common each one is. That summary is refreshed by ANALYZE and autovacuum, but not the instant your data changes. Right after a big load it still describes the old, empty table, so the planner estimates one matching row when there are really about a hundred and plans accordingly. Running ANALYZE by hand rebuilds the summary and the estimates snap back to reality.
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.