Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA4eK1KxqBhk-hc1r9AehvPpaZrt0-TJZdQa-kHJZ2MhZvCOYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Thom Brown <thom@linux.com>)
Ответы Re: Parallel Seq Scan
Список 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 по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Thom Brown
Дата:
Сообщение: Re: Parallel Seq Scan