Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1KxqBhk-hc1r9AehvPpaZrt0-TJZdQa-kHJZ2MhZvCOYQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Thom Brown <thom@linux.com>)
Responses Re: Parallel Seq Scan  (Thom Brown <thom@linux.com>)
List pgsql-hackers
On Fri, Nov 13, 2015 at 7:59 PM, Thom Brown <thom@linux.com> wrote:
>
> On 13 November 2015 at 13:38, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Wed, Nov 11, 2015 at 11:40 PM, Pavel Stehule <pavel.stehule@gmail.com>
> > wrote:
> >>
> >>
> >> yes - the another little bit unclean in EXPLAIN is number of workers. If I
> >> understand to the behave, the query is processed by two processes if workers
> >> in the explain is one.
> >>
> >
> > You are right and I think that is current working model of Gather
> > node which seems okay. I think the more serious thing here
> > is that there is possibility that Explain Analyze can show the
> > number of workers as more than actual workers working for Gather
> > node.  We have already discussed that Explain Analyze should
> > the actual number of workers used in query execution, patch for
> > the same is still pending.
>
> This may have already been discussed before, but in a verbose output,
> would it be possible to see the nodes for each worker?
>

There will be hardly any difference in nodes for each worker and it could
be very long plan for large number of workers.  What kind of additional
information you want which can't be shown in current format.
 
>
> And perhaps associated PIDs?
>

Yeah, that can be useful, if others also feel like it is important, I can
look into preparing a patch for the same.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Parallel Seq Scan
Next
From: Thom Brown
Date:
Subject: Re: Parallel Seq Scan