Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation - Mailing list pgsql-hackers

From Maciek Sakrejda
Subject Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation
Date
Msg-id CAOtHd0BkV4usnJfki2KzHtepD9cx3oU_pavS3EPJPE2SyYDgXA@mail.gmail.com
Whole thread Raw
In response to Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, Jun 24, 2020 at 2:44 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> So, that leads to loops as 2 on "Parallel Seq Scan" and "Nested Loop" nodes.  Does this make sense now?

Yes, I think we're on the same page. Thanks for the additional details.

It turns out that the plan I sent at the top of the thread is actually
an older plan we had saved, all the way from April 2018. We're fairly
certain this was Postgres 10, but not sure what point release. I tried
to reproduce this on 10, 11, 12, and 13 beta, but I am now seeing
similar results to yours: Buffers and I/O Timings are rolled up into
the parallel leader, and that is propagated as expected to the Gather.
Sorry for the confusion.

On Wed, Jun 24, 2020 at 3:18 AM Maciek Sakrejda <m.sakrejda@gmail.com> wrote:
>So we should be seeing an average, not a sum, right?

And here I missed that the documentation specifies rows and actual
time as per-loop, but other metrics are not--they're just cumulative.
So actual time and rows are still per-"loop" values, but while rows
values are additive (the Gather combines rows from the parallel leader
and the workers), the actual time is not because the whole point is
that this work happens in parallel.

I'll report back if I can reproduce the weird numbers we saw in that
original plan or find out exactly what Postgres version it was from.

Thanks,
Maciek



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2
Next
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions