On Tue, May 1, 2018 at 4:57 PM, Andres Freund <andres@anarazel.de> wrote:
> Robert, you added this as an open item. I don't think it's clear that
> there's a bug here, and even less clear that it's something new for
> v11. Am I understanding that right? Should we close this open item?
Yeah, I added it in response to the original post, but it sounds like
this is just another case of somebody being confused by the fact that
EXPLAIN divides the row counts, startup time, total time, and number
of rows filtered by the loop count. So it's not an open item.
That having been said, what I think we ought to do about the confusion
that regularly results from that logic is rip it out, as in the
attached patch. This would affect not only the parallel query case
but also the inner sides of nested loops, but that doesn't bother me a
bit because I think dividing is unhelpful in both cases. Note that
explain.depesz.com, for example, goes and re-multiplies the times by
the loop count to get a figure for how much time was spent in that
node; I regularly do the same thing by hand when I read such EXPLAIN
output. Also, if you did think those cases should be handled
differently, you'd have to explain what should happen when there's a
nested loop that gets run by multiple workers, possibly different
numbers of times in each one.
One problem with this patch is that tools like explain.depesz.com (or
my brain) would need to know if they were getting output from 11+ or
10-, so it might be good to perturb this output in some other way so
as to avoid confusion, like by replacing "loops=" with some other
text. I don't have a specific proposal for that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
