Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation

Поиск
Список
Период
Сортировка
От Maciek Sakrejda
Тема Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation
Дата
Msg-id CAOtHd0DaxfNb79=Y3QbbREJAUwuX3Sc0XcidUBZ084_F=7yPAw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: should libpq also require TLSv1.2 by default?
Следующее
От: Takashi Menjo
Дата:
Сообщение: RE: [PoC] Non-volatile WAL buffer