Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE - Mailing list pgsql-hackers

From David Rowley
Subject Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
Date
Msg-id CAApHDvpAz_wVNXeCEhjyxcXM6yXMhs+wG+3vywDaJptj6w7dRA@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Pluggable cumulative statistics
Next
From: Michael Paquier
Date:
Subject: Re: Internal error codes triggered by tests