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
|
Список | 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 по дате отправления: