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
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 |