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?
|
Список | 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 по дате отправления: