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 CAOtHd0DaxfNb79=Y3QbbREJAUwuX3Sc0XcidUBZ084_F=7yPAw@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>)
Responses Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation
List pgsql-hackers
On Tue, Jun 23, 2020 at 7:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I don't see any other reason for
> > looping over the NL node itself in this plan. The Gather itself
> > doesn't do any real looping, right?
>
> It is right that Gather doesn't do looping but Parallel Seq Scan node does so.

Sorry, I still don't follow. How does a Parallel Seq Scan do looping?
I looked at the parallel plan docs but I don't see looping mentioned
anywhere[1]. Also, is looping not normally indicated on children,
rather than on the node doing the looping? E.g., with a standard
Nested Loop, the outer child will have loops=1 and the inner child
will have loops equal to the row count produced by the outer child
(and the Nested Loop itself will have loops=1 unless it also is being
looped over by a parent node), right?

But even aside from that, why do I need to divide by the number of
loops here, when normally Postgres presents a per-loop average?

[1]: https://www.postgresql.org/docs/current/parallel-plans.html



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: should libpq also require TLSv1.2 by default?
Next
From: Takashi Menjo
Date:
Subject: RE: [PoC] Non-volatile WAL buffer