| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Masahiro(dot)Ikeda(at)nttdata(dot)com |
| Cc: | lena(dot)ribackina(at)yandex(dot)ru, donghanglin(at)gmail(dot)com, geidav(dot)pg(at)gmail(dot)com, melanieplageman(at)gmail(dot)com, tomas(dot)vondra(at)enterprisedb(dot)com, dilipbalaut(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, hlinnaka(at)iki(dot)fi |
| Subject: | Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE |
| Date: | 2024-07-05 00:52:28 |
| Message-ID: | CAApHDvpAz_wVNXeCEhjyxcXM6yXMhs+wG+3vywDaJptj6w7dRA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 5 Jul 2024 at 01:59, David Rowley <dgrowleyml(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-07-05 00:57:19 | Re: Internal error codes triggered by tests |
| Previous Message | Michael Paquier | 2024-07-05 00:35:19 | Re: Pluggable cumulative statistics |