From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation |
Date: | 2020-06-24 02:55:15 |
Message-ID: | CAA4eK1Khp6DjLzS2KKP_u6BTvKzEqKWburp7GBnaEQRX8fi+zQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 24, 2020 at 3:18 AM Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> wrote:
>
> On Tue, Jun 23, 2020 at 2:57 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > I don't think this is an odd situation because in this case, child
> > nodes like "Nested Loop" and "Parallel Seq Scan" has a value of
> > 'loops' as 3. So, to get the correct stats at those nodes, you need
> > to divide it by 3 whereas, at Gather node, the value of 'loops' is 1.
> > If you want to verify this thing then try with a plan where loops
> > should be 1 for child nodes as well, you should get the same value at
> > both Gather and Parallel Seq Scan nodes.
>
> Thanks for the response, but I still don't follow. I had assumed that
> loops=3 was just from loops=1 for the parallel leader plus loops=1 for
> each worker--is that not right?
>
No, I don't think so.
> 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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-06-24 02:56:38 | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 |
Previous Message | Kyotaro Horiguchi | 2020-06-24 02:15:40 | Re: Review for GetWALAvailability() |