Horton

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

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Masahiro.Ikeda@nttdata.com
Cc: lena.ribackina@yandex.ru, donghanglin@gmail.com, geidav.pg@gmail.com, melanieplageman@gmail.com, tomas.vondra@enterprisedb.com, dilipbalaut@gmail.com, pgsql-hackers@lists.postgresql.org, hlinnaka@iki.fi
Date: 2024-07-05T00:52:28Z
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 Fri, 5 Jul 2024 at 01:59, David Rowley <dgrowleyml@gmail.com> wrote:
> I also made a pass over the patch, and I also changed:
>
> 1. Fixed up a few outdated comments in execnodes.h.
> 2. Added a comment in ExecEndBitmapHeapScan() to explain why we += the
> stats rather than memcpy the BitmapHeapScanInstrumentation.
> 3. A bunch of other comments.
> 4. updated typedefs.list and ran pgindent.

One other thing I think we should do while on this topic is move away
from using "long" as a data type for storing the number of exact and
lossy pages. The problem is that sizeof(long) on 64-bit MSVC is 32
bits. A signed 32-bit type isn't large enough to store anything more
than 16TBs worth of 8k pages.

I propose we change these to uint64 while causing churn in this area,
probably as a follow-on patch.  I think a uint32 isn't wide enough as
you could exceed the limit with rescans.

David