On Thu, Mar 6, 2025 at 1:58 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Thu, Mar 6, 2025 at 1:54 PM Robert Haas <robertmhaas@gmail.com> wrote:
> > Hmm, it seems weird that you can't get a hold of that structure to me.
> > Why can't you just go find it in the DSM?
>
> Sorry, I was unclear.
>
> One reason is that there isn't necessarily anything to find.
> Certainly, when I try this out with a debugger, even the B-Tree scan
> doesn't have doesn't even have IndexScanDescData.parallel_scan set. It
> isn't actually a parallel B-Tree scan. It is a
> serial/non-parallel-aware index scan that is run from a parallel
> worker, and feeds its output into a gather merge node despite all
> this.
Well, I think this calls the basic design into question. We discussed
putting this into IndexScanDescData as a convenient way of piping it
through to EXPLAIN, but what I think we have now discovered is that
there isn't actually convenient at all, because every process has its
own IndexScanDescData and the leader sees only its own. It seems like
what you need is to have each process accumulate stats locally, and
then at the end total them up. 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.
--
Robert Haas
EDB: http://www.enterprisedb.com