ANALYZE the partitioned parent autovacuum never will
Autovacuum keeps every partition's statistics fresh and never touches the parent's, because the counter it watches on the parent never moves. Queries planned across the whole table then run on statistics nobody has updated since the day it was created.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
A partitioned table has statistics at two levels: each partition has its own, and the parent has a set describing the whole table that the planner uses when a query spans partitions. Autovacuum maintains the first and structurally cannot maintain the second, so the parent's statistics are only ever as fresh as the last manual ANALYZE.
Meridian partitions its events table by month and loads rows continuously into the current partition. Every partition is autoanalyzed within minutes of a load. The parent has never been analyzed since creation, and cross-partition reports are planned from that empty picture — so estimates drift further from reality every month while every monitoring check reports healthy.
In plain English
A partitioned table is really a family: one parent that you query, and the child tables that hold the rows. Statistics — the planner's summary of what the data looks like — exist for both. Autovacuum keeps each child's summary up to date automatically, because it watches a per-table counter of how many rows changed. The catch is that inserting into a child only moves the child's counter. The parent's counter stays at zero no matter how much data arrives, so the automatic maintenance that depends on it can never trigger. The result is a parent whose summary is however stale it was when someone last ran ANALYZE by hand, which for most tables means never — and any query that spans partitions is planned from that.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Vacuum & bloat runbooks
Neighbouring incidents that share the same diagnostic surface.
Connected
How this connects to the rest of the library
A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.
Fixes these errors