Partition a growing table so the planner can prune
Range partitioning by month lets the planner skip every partition a query does not need. A date-equality query scans only shipments_2024_02 instead of the whole table.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
A single enormous table forces every query to consider all of it. Range partitioning splits it by a key (say month), and the planner prunes to just the partitions a query's predicate can match, reading a fraction of the data.
Meridian's shipments grow forever. Partitioning by month means a query for one day only touches that month's partition; the rest are pruned before execution.
Simple terms
One giant table forces every query to reckon with all of it. Range partitioning slices the table by a key, a month, say, into smaller child tables. When a query filters on that key, the planner can "prune" away every partition that cannot possibly match and read only the one that can. A query for a single day then touches just that month's slice instead of the whole history.
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
More in this category
Other Schema migrations 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.
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.