On Thu, Mar 6, 2025 at 1:58 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Thu, Mar 6, 2025 at 1:54 PM Robert Haas <robertmh...@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
