BitmapAnd

BitmapAnd combines the bitmaps from two or more Bitmap Index Scans by intersection, keeping only rows that match all of them — the plan-level equivalent of ANDing several indexed conditions.

When multiple indexed conditions are combined with AND and the planner decides combining indexes beats using one.

A sign PostgreSQL is using several indexes together. If it shows up a lot for the same query shape, a single composite index may be faster.

Intersecting bitmaps

BitmapAnd takes two or more bitmaps from sibling Bitmap Index Scans and returns the intersection — rows that match every input. It's how PostgreSQL keeps an AND across several indexed columns served by indexes, without requiring a single composite index that covers all of them.

Bitmap Heap Scan on orders
  Recheck Cond: …
  ->  BitmapAnd  (rows=120)
        ->  Bitmap Index Scan on orders_customer_idx
              Index Cond: customer_id = 42
        ->  Bitmap Index Scan on orders_status_idx
              Index Cond: status = 'open'

When a composite index is better

A BitmapAnd of two separate indexes is fine; a frequent BitmapAnd on the same pair of columns is a hint that a composite index would be faster:

CREATE INDEX ON orders (customer_id, status);

A composite index locates the matching rows in one descent of the B-tree instead of two scans plus an AND.

Lossy bitmaps still apply

Combined bitmaps go through the same work_mem accounting as a single bitmap. If the result is huge, you can still hit a lossy block-level bitmap upstream at the Bitmap Heap Scan — raising work_mem for the query restores per-tuple precision.

• BitmapOr
• Bitmap Index Scan
• Bitmap Heap Scan