Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Christofides <michael@pgmustard.com>
Cc: David Geier <geidav.pg@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-17T17:57:22Z
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

On Mon, Oct 16, 2023 at 12:31 PM Michael Christofides
<michael@pgmustard.com> wrote:
> 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.

I think you're wrong about that. The bitmap index scans are what scan
the indexes and build the bitmap. The bitmap heap scan node is what
scans the heap i.e. the table, and that is what is divided across the
workers.

On the patch itself, snapshot_and_stats doesn't strike me as a great
name. If we added three more variable-length things would we call the
member snapshot_and_stats_and_pink_and_orange_and_blue? Probably
better to pick a name that is somehow more generic.

-- 
Robert Haas
EDB: http://www.enterprisedb.com