From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Georgios Kokolatos <gkokolatos(at)pm(dot)me>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Duplicate Workers entries in some EXPLAIN plans |
Date: | 2020-01-25 19:23:50 |
Message-ID: | 31439.1579980230@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
merge-explain-worker-output-v7.patch | text/x-diff | 27.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-25 23:20:16 | Re: Duplicate Workers entries in some EXPLAIN plans |
Previous Message | Noah Misch | 2020-01-25 19:23:07 | Re: Strange coding in _mdfd_openseg() |