Tame a lossy bitmap heap scan
When a bitmap scan runs out of work_mem it stops tracking individual rows and rechecks whole pages. Spot the lossy switch and size work_mem so 56,903 wasted rechecks disappear.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
A Bitmap Heap Scan builds a bitmap of matching rows in work_mem. If the bitmap does not fit, PostgreSQL degrades it to page granularity ("lossy") and rechecks every row on those pages, CPU you cannot see in the row counts.
A Meridian delivery_logs report scans a few percent of an 800,000-row table. At a small work_mem the bitmap goes lossy and the scan rechecks tens of thousands of rows it did not need to.
Simple terms
A bitmap scan works in two steps: first it builds a list of which rows match, then it goes and fetches them. That list lives inside a memory budget called work_mem. If the list is too big to fit, PostgreSQL stops tracking individual rows and only remembers whole pages instead, then it has to re-check every row on those pages to see which ones actually matched. That re-checking never shows up in the row counts; it just quietly burns CPU. Give the query enough work_mem and the list stays exact, so no page has to be re-checked.
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 Query performance 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
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.