On Tue, May 1, 2018 at 4:57 PM, Andres Freund <and...@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
no-loop-division.patch
Description: Binary data