Track ANALYZE progress on large and partitioned tables
ANALYZE on a partitioned table is really one job per partition plus one for the parent. pg_stat_progress_analyze shows which child it is on and how many sample blocks are left, sample the view while ANALYZE runs.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Statistics collection on a large partitioned table can take long enough that people assume it has hung, and there is no output until it commits. The parent and each child are separate units of work, so a single elapsed time tells you nothing about how far along you are.
consignment_history has four quarterly LIST partitions and reltuples is still -1 on all of them, which means nothing has ever been analyzed. Plans on the table are bad and an ANALYZE is about to fix them.
Simple terms
ANALYZE gathers the statistics the planner depends on, and on a big partitioned table it is really one job per partition plus one for the parent, with no output until it finishes. So a single elapsed time tells you nothing about how far along it is. pg_stat_progress_analyze shows which child partition it is working on and how many sample blocks are left, turning "is this hung?" into an actual progress bar.
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 Observability 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.