On Thu, Mar 6, 2025 at 2:12 PM Robert Haas <robertmhaas@gmail.com> wrote:
> Maybe show_sort_info() has some useful
> precedent, since that's also a bit of node-specific instrumentation,
> and it seems to know what to do about workers.
What do you think of the attached WIP patch, which does things this
way? Does this seem like the right general direction to you?
Unfortunately, my new approach seems to require quite a bit more code,
including adding new parallel query functions for bitmap index scans
(which previously didn't require anything like this at all). I can
probably simplify it some more, but likely not by much.
I now put a pointer to an instrumentation struct in IndexScanDescData.
The pointer always points to local memory: specifically, it points to
a dedicated field in each of the 3 supported executor node planstate
structs. Each of the workers copy their local instrumentation struct
into a dedicated space in shared memory, at the point that
ExecIndexScanRetrieveInstrumentation/ExecIndexOnlyScanRetrieveInstrumentation/ExecBitmapIndexScanRetrieveInstrumentation
is called (though only when running during EXPLAIN ANALYZE). Once we
get to explain.c, we take more or less the same approach already used
for things like sort nodes and hash join nodes.
Obviously, this revised version of the patch passes all tests when the
tests are run with debug_parallel_query=regress.
--
Peter Geoghegan
