Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Hubert Lubaczewski <depesz@depesz.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>
Date: 2017-11-28T16:07:45Z
Lists: pgsql-hackers
On Mon, Nov 27, 2017 at 6:54 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> Anything "below" "Gather"? >> > I think it is "actual_time * 1" for anything below Gather. The actual time amounts below Gather show total elapsed time divided by loop count, just as they do anywhere else in the plan. The loop count tracks the number of times the plan was executed, just as it does anywhere else in the plan. So for example if there are 5 participants which each execute the node once, and the times spent are 5 s, 60 s, 60 s, 60 s, and 60 s, you'll get actual time = 49 s, loops = 5. If you want to know the total amount of time spent under the node, then you have to multiply the actual time (49 s in this example) by the loop count (5 in this example) just as you would for any other plan node. However, you have to keep in mind that, for a parallel query, the total time spent under the node is not the same as the elapsed time. In this example, if all 5 workers started at the same time and ran the node continuously without a break, the *elapsed* time until they all finished would be 60 s, not 49 s, a value that EXPLAIN will report nowhere. But they can also start and stop executing under that node repeatedly and they need not all start at the same time, making the concept of elapsed time a bit unclear -- earliest start to latest finish would be one way, but that will be misleading (perhaps) if they spend 5 seconds a piece but start staggered at 4 second intervals. It's really hard to understand what's actually going on with a parallel query unless you look at each worker individually, and even then sometimes it's not as clear as it could be. I'm not sure what to do about that. Elsewhere, trying to show the leader's information separately when VERBOSE is used has been discussed, and I think that's a good idea, but it may not be enough. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Back-port fix for accumulation of parallel worker instrumentation.
- 2157a61b5aa3 9.6.7 landed
-
Test instrumentation of Hash nodes with parallel query.
- 7d3583ad9ae5 11.0 landed
-
Try again to fix accumulation of parallel worker instrumentation.
- 72567f617460 10.2 landed
- 8526bcb2df76 11.0 landed
-
Revert "Fix accumulation of parallel worker instrumentation."
- 7b3f85073c8d 10.2 landed
- 1d6fb35ad629 11.0 landed
-
Fix accumulation of parallel worker instrumentation.
- 778e78ae9fa5 10.2 landed
- 2c09a5c12a66 11.0 landed