Horton

Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE

Michael Christofides <michael@pgmustard.com>

View thread
From: Michael Christofides <michael@pgmustard.com>
To: David Geier <geidav.pg@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-16T16:29:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Show Parallel Bitmap Heap Scan worker stats in EXPLAIN ANALYZE

  2. Widen lossy and exact page counters for Bitmap Heap Scan

  3. Remove redundant snapshot copying from parallel leader to workers

> EXPLAIN ANALYZE for parallel Bitmap Heap Scans currently only reports
> the number of heap blocks processed by the leader. It's missing the
> per-worker stats.


Hi David,

According to the docs[1]: "In a parallel bitmap heap scan, one process is
chosen as the leader. That process performs a scan of one or more indexes
and builds a bitmap indicating which table blocks need to be visited. These
blocks are then divided among the cooperating processes as in a parallel
sequential scan."

My understanding is that the "Heap Blocks" statistic is only reporting
blocks for the bitmap (i.e. not the subsequent scan). As such, I think it
is correct that the workers do not report additional exact heap blocks.


> explain (analyze, costs off, timing off) select * from foo where col0 >
> 900 or col1 = 1;
>

In your example, if you add the buffers and verbose parameters, do the
worker reported buffers numbers report what you are looking for?

i.e. explain (analyze, buffers, verbose, costs off, timing off) select *
from foo where col0 > 900 or col1 = 1;

—
Michael Christofides
Founder, pgMustard <https://pgmustard.com/>

[1]:
https://www.postgresql.org/docs/current/parallel-plans.html#PARALLEL-SCANS