On Mon, Nov 27, 2017 at 2:45 PM, hubert depesz lubaczewski <dep...@depesz.com> wrote: > On Sat, Nov 25, 2017 at 07:08:03AM +0530, Amit Kapila wrote: >> > 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 >> > 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. > > Please check the plans: > https://explain.depesz.com/s/gNBd (step 13) > and https://explain.depesz.com/s/LTMp (step 3) > > Inclusive time is basically "loops * actual time", so for Index Scan, > which had 1873 loops and actual time of 3.002..3.016, we got 1873 > * 3.016 = 5648.968ms. > > In case of parallel workers it looks like the inclusive time is > basically the upper value from actual time. > > The question now is: how can I tell which nodes should use "actual_time > * 1" and which "actual_time * loops" time? > > Anything "below" "Gather"? >
I think it is "actual_time * 1" for anything below Gather. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
