Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA4eK1KNYQtcB78o46prtrJknGGorRwAFgU4JPT9qMZ7YcKhbQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Parallel Seq Scan
Список pgsql-hackers
On Wed, Apr 8, 2015 at 3:30 PM, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On 8 April 2015 at 15:46, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> I think there is always a chance that resources (like parallel-workers)
>> won't be available at run-time even if we decide about them at
>> executor-start phase unless we block it for that node's usage and OTOH
>> if we block it (by allocating) those resources during executor-start phase
>> then we might end up blocking it too early or may be they won't even get
>> used if we decide not to execute that node.  On that basis, it seems to
>> me current strategy is not bad where we decide during planning time and
>> later during execution time if not all resources (particularly parallel-workers)
>> are not available, then we use only the available one's to execute the plan.
>> Going forward, I think we can improve the same if we decide not to shutdown
>> parallel workers till postmaster shutdown once they are started and
>> then just allocate them during executor-start phase.
>>
>>
>
> Yeah, but what about when workers are not available in cases when the plan was only a win because the planner thought there would be lots of workers... There could have been a more optimal serial plan already thrown out by the planner which is no longer available to the executor.
>

That could also happen even if we decide in executor-start phase.
I agree that there is a chance of loss incase appropriate resources
are not available during execution, but same is true for work_mem
as well for a non-parallel plan.  I think we need some advanced way
to handle the case when resources are not available during execution
by either re-planing the statement or by some other way, but that can
also be done separately.

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Removal of FORCE option in REINDEX
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: Replication identifiers, take 4