MIME-Version: 1.0
References: <b3d80961-c2e5-38cc-6a32-61886cdf766d@gmail.com>
 <CAFiTN-v1yDvU=X+hwfJ+55=sbgDj=_kuvbduEG-F7=BjpWcnuw@mail.gmail.com>
 <efcb213c-c87c-41f0-85b7-7fa8079df807@enterprisedb.com> <CAA=D8a1ZGWTk0RDH-LyU==RsE-217T29eprS-NBhyj+eLHyRrQ@mail.gmail.com>
 <CAAKRu_YjBPfGp85ehY1t9NN=R9pB9k=6rztaeVkAm-OeTqUK4g@mail.gmail.com>
 <CAA=D8a1G5CgvdWLd5_VCEc5Sa3rgJftcGfTEvYqG1HnjMBQmpA@mail.gmail.com>
 <13bd913f-94b6-43cf-b849-4d762e5297d8@yandex.ru> <TYWPR01MB10982C38F6BD6BE4D1D5CCC5EB1D62@TYWPR01MB10982.jpnprd01.prod.outlook.com>
 <CAApHDvqsTB-zNw_SpcujnYCi6FYN3M16kJn9QX7pHtVq5wP_Lw@mail.gmail.com>
In-Reply-To: <CAApHDvqsTB-zNw_SpcujnYCi6FYN3M16kJn9QX7pHtVq5wP_Lw@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 5 Jul 2024 12:52:28 +1200
Message-ID: <CAApHDvpAz_wVNXeCEhjyxcXM6yXMhs+wG+3vywDaJptj6w7dRA@mail.gmail.com>
Subject: Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
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
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAApHDvpAz_wVNXeCEhjyxcXM6yXMhs%2BwG%2B3vywDaJptj6w7dRA%40mail.gmail.com>
Precedence: bulk

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