Re: Rename max_parallel_degree?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Rename max_parallel_degree?
Дата
Msg-id CA+TgmoZ4MdcMR7XC_6t1LfHhSskwX5h2Wris58b=gBHFJjjfUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rename max_parallel_degree?  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Rename max_parallel_degree?  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Thu, Jun 9, 2016 at 2:05 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> OK, I pushed this after re-reviewing it and fixing a number of
>> oversights.  There remains only the task of adding max_parallel_degree
>> as a system-wide limit (as opposed to max_parallel_degree now
>> max_parallel_workers_per_gather which is a per-Gather limit), which
>> I'm going to argue should be a new open item and not necessarily one
>> that I have to own myself.  I would like to take care of it, but I
>> will not put it ahead of fixing actual defects and I will not promise
>> to have it done in time for 9.6.
>
> I am in favor of having something similar to
> max_parallel_workers_per_gather for utility statements like CREATE
> INDEX. That will need a cost model, at least where the DBA isn't
> explicit about the number of workers to use.

We may well need that, but I think it should be discussed in
conjunction with the patches that add parallelism for those utility
statements, rather than discussing it on a thread for a 9.6 open item.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Parallel safety tagging of extension functions