Re: Rename max_parallel_degree?
От | Josh Berkus |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | 57581603.3040309@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Rename max_parallel_degree?
|
Список | pgsql-hackers |
On 06/07/2016 11:01 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 9:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> I think we should just go with max_parallel_workers for a limit on >>> total parallel workers within max_work_processes, and >>> max_parallel_workers_per_gather for a per-Gather limit. It's slightly >>> annoying that we may end up renaming the latter GUC, but not as >>> annoying as spending another three weeks debating this and missing >>> beta2. >> >> +1. I'm not as convinced as you are that we'll replace the GUC later, >> but in any case this is an accurate description of the current >> semantics. And I'm really *not* in favor of fudging the name with >> the intent of changing the GUC's semantics later --- that would fail >> all sorts of compatibility expectations. > > Here's a patch change max_parallel_degree to > max_parallel_workers_per_gather, and also changing parallel_degree to > parallel_workers. I haven't tackled adding a separate > max_parallel_workers, at least not yet. Are people OK with this? +1 > > Note that there is a dump/restore hazard if people have set the > parallel_degree reloption on a beta1 install, or used ALTER { USER | > DATABASE } .. SET parallel_degree. Can everybody live with that? > Should I bump catversion when applying this? IMHO, we just need to call it out in the beta2 announcement. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
В списке pgsql-hackers по дате отправления: