IPC:ParallelBitmapScan
ParallelBitmapScan is a PostgreSQL wait event that occurs when a parallel worker is waiting to participate in a parallel bitmap heap scan.
The bitmap itself is generated by the leader process via a (non-parallel) bitmap index scan. Workers then coordinate to scan the heap pages referenced in the shared bitmap.
parallel workers pause until the leader process sets up a shared bitmap structure. This bitmap is used to efficiently mark and gather candidate rows from index scans before accessing the heap (table data).
The ParallelBitmapScan wait indicates that a worker is idle, waiting for its turn or for coordination with other workers to safely and efficiently access the shared bitmap and underlying heap pages.
What causes excessive ParallelBitmapScan
Large-Scale Data Retrieval: When a query uses an index but still needs to fetch a significant percentage of a large table. PostgreSQL often chooses a Bitmap Scan to keep I/O sequential. If the table is large enough, it uses parallel workers to speed it up.
- Uneven Data Distribution (Skew): If one worker gets a "chunk" of the table that is very dense with relevant rows, and another worker gets a "chunk" that is nearly empty, the second worker will finish quickly and sit in the ParallelBitmapScan wait state while waiting for the others to finish or for the next instructions.
- High Parallelism Overhead : If max_parallel_workers_per_gather is set too high for a relatively small table, the workers spend more time talking to each other (IPC) than they do actually reading data from the disk.
How to reduce ParallelBitmapScan waits
- Reduce max_parallel_workers_per_gather: Sometimes 2 workers are more efficient than 8 because there is less "cross-talk" on the shared bitmap.
- Increase min_parallel_table_scan_size: This prevents PostgreSQL from trying to use parallel scans on tables that are too small to benefit from it.
- Check Memory (Work_Mem): Parallel Bitmap Scans rely on the bitmap fitting into memory. If work_mem is too low, the bitmap might become "lossy" (tracking entire pages instead of individual rows), which increases the I/O load and can indirectly increase coordination time.
References
Parallel Scans in PostgreSQL