Lossy Bitmap Blocks: When the Bitmap Remembers Pages, Not Rows (Recheck Cond)
The bitmap a scan builds lives in work_mem. If the matching rows do not fit, PostgreSQL degrades gracefully by remembering whole pages instead of individual rows, and the plan reports 'lossy=N' alongside 'exact=N'. The consequence is that the heap step must re-check the condition on every row of those pages, which is what the Recheck Cond line in the plan is doing, and it costs real CPU. A high lossy count is a quiet signal that more memory or a tighter condition would pay off.
Questions this Concept answers
Why does a lossy bitmap force the heap step to run a `Recheck Cond`?
J
jeremy
Video
Reading Bitmap Heap Scans in PostgreSQL EXPLAIN Plans
A bitmap heap scan is a two-phase access method in which an index scan first materializes an in-memory bitmap of tuple identifiers satisfying the predicate, and the heap is then read in physical page…