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

  1. Back-port fix for accumulation of parallel worker instrumentation.

  2. Test instrumentation of Hash nodes with parallel query.

  3. Try again to fix accumulation of parallel worker instrumentation.

  4. Revert "Fix accumulation of parallel worker instrumentation."

  5. Fix accumulation of parallel worker instrumentation.