Partial indexes for hot subsets of data
If queries only ever touch a small slice of a table, index just that slice. A partial index on exception rows is ~280 kB versus ~4 MB for the full status index, smaller, faster, cheaper to maintain.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Indexing an entire column when queries only ever hit a fraction of it wastes space and write cost. A WHERE clause on the index restricts it to the rows that matter, so it stays small and cache-friendly.
Meridian's delivery_attempts has 100,000 rows, but the dashboard only queries status = 'exception' (~2,500 rows). A full index on status indexes every ok row nobody filters for; a partial index covers only the hot subset.
Simple terms
If your queries only ever look at a small slice of a table, exception rows, say, there is no point indexing the tens of thousands of ordinary rows nobody reads that way. A partial index carries a WHERE clause of its own, so it covers only the rows that matter. It stays small, fits in cache, and costs less to maintain on every write.
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 Indexing 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.