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
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 |