Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: depesz(at)depesz(dot)com
Cc: pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com
Date: 2017-11-25 01:38:03
Message-ID: CAA4eK1JwC4n1XyXnvk=vC0WkAFAM0T++xuNr79c+jX3eVTrOwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 24, 2017 at 4:51 PM, hubert depesz lubaczewski
<depesz(at)depesz(dot)com> wrote:
> Hi,
>
> up to parallel executions, when we had node in explain analyze showing
> "loops=x" with x more than 1, it meant that the "actual time" had to be
> multiplied by loops to get real time spent in a node.
>
> For example, check step 13 in https://explain.depesz.com/s/gNBd
>
> It shows time of 3ms, but loops of 1873, so the actual time is ~ 5600ms.
>
> But with parallel execution it seems to be no longer the case.
>
> For example:
> https://explain.depesz.com/s/LTMp
> or
> https://explain.depesz.com/s/QHRi
>
> It looks that the actual time is really actual time, and loops is
> "worker nodes + 1".
>
> Is that really the case?
>

I think so.

> Should I, for explain.depesz.com, when dealing
> with partial* and parallel* nodes, use "loops=1" for calculation of
> exclusive/inclusive time? always? some other nodes?
>

I am not sure what exactly inclusive or exclusive means, but for
parallel nodes, total stats are accumulated so you are seeing loops as
'worker nodes + 1'. Now, as presumably workers run parallelly, so I
think the actual time will be what will be shown in the node not
actual time * nloops.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-11-25 02:09:42 Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted
Previous Message Jeff Janes 2017-11-25 01:20:02 Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted