Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Hubert Lubaczewski <depesz@depesz.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>
Date: 2017-11-29T08:36:57Z
Lists: pgsql-hackers
On Tue, Nov 28, 2017 at 9:37 PM, Robert Haas <robertmhaas@gmail.com> wrote: > 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 think stats at Gather node itself gives a somewhat right picture. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
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