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
- merge-explain-worker-output-v7.patch (text/x-diff) patch v7
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
-
Clean up EXPLAIN's handling of per-worker details.
- 100136849704 13.0 landed