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

From: Michael Christofides <michael(at)pgmustard(dot)com>
To: David Geier <geidav(dot)pg(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
Date: 2023-10-16 16:29:37
Message-ID: CAFwT4nDDc+HOpGnwau5ys9ADqJ3gZfbRGomMRuiiQ=1ToXq3Mg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2023-10-16 17:00:11 Re: The danger of deleting backup_label
Previous Message David G. Johnston 2023-10-16 16:26:47 Improving Physical Backup/Restore within the Low Level API