Re: Duplicate Workers entries in some EXPLAIN plans

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maciek Sakrejda <m.sakrejda@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Georgios Kokolatos <gkokolatos@pm.me>, pgsql-hackers@lists.postgresql.org
Date: 2020-01-25T19:23:50Z
Lists: pgsql-hackers

Attachments

Maciek Sakrejda <m.sakrejda@gmail.com> writes:
> For what it's worth, this version makes sense to me.

Thanks for looking.  Here's a version that deals with the JIT
instrumentation.  As Andres noted far upthread, that was also
really bogusly done before.  Not only could you get multiple "JIT"
subnodes on a Gather node, but we failed to print the info at all
if the parallelism was expressed as Gather Merge rather than
Gather.

A side effect of this change is that per-worker JIT info is now
printed one plan level further down: before it was printed on
the Gather node, but now it's attached to the Gather's child,
because that's where we print other per-worker data.  I don't
see anything particularly wrong with that, but it's another
change from the behavior today.

It's still really unclear to me how we could exercise any of
this behavior meaningfully in a regression test.  I thought
for a little bit about using the TAP infrastructure instead
of a traditional-style test, but it seems like that doesn't
buy anything except for a bias towards ignoring details instead
of overspecifying them.  Which is not much of an improvement.

			regards, tom lane

Commits

  1. Clean up EXPLAIN's handling of per-worker details.