Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: David Geier <geidav.pg@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-17T20:14: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 →
-
Show Parallel Bitmap Heap Scan worker stats in EXPLAIN ANALYZE
- 5a1e6df3b84c 18.0 landed
-
Widen lossy and exact page counters for Bitmap Heap Scan
- 7340d9362a79 18.0 landed
-
Remove redundant snapshot copying from parallel leader to workers
- 84c18acaf690 17.0 cited
> On Tue, Feb 21, 2023 at 01:02:35PM +0100, David Geier wrote: > Hi, > > On 1/20/23 09:34, David Geier wrote: > > 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. The attached patch adds that functionality in the > > spirit of e.g. Sort or Memoize. Here is a simple test case and the > > EXPLAIN ANALYZE output with and without the patch: > > Attached is a rebased version of the patch. I would appreciate someone > taking a look. > > As background: the change doesn't come out of thin air. We repeatedly took > wrong conclusions in our query analysis because we assumed that the reported > block counts include the workers. > > If no one objects I would also register the patch at the commit fest. The > patch is passing cleanly on CI. Thanks for the patch. The idea sounds reasonable to me, but I have to admit snapshot_and_stats implementation looks awkward. Maybe it would be better to have a separate structure field for both stats and snapshot, which will be set to point to a corresponding place in the shared FAM e.g. when the worker is getting initialized? shm_toc_allocate mentions BUFFERALIGN to handle possibility of some atomic operations needing it, so I guess that would have to be an alignment in this case as well. Probably another option would be to allocate two separate pieces of shared memory, which resolves questions like proper alignment, but annoyingly will require an extra lookup and a new key.