Re: Rename max_parallel_degree?
От | Robert Haas |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | CA+TgmobYx11xuXy_GtuT=1ejh27K5t-jrc=gOk+XWhxUbpLbkQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Rename max_parallel_degree?
|
Список | pgsql-hackers |
On Fri, Jun 3, 2016 at 8:30 AM, David G. Johnston <david.g.johnston@gmail.com> wrote: > How big is the hazard of future-naming this and documenting the present > limitation? Is the casual user reading explains even going to be aware of > that particular implementation detail? Well, see, the nice thing about max_parallel_degree is that it is very slightly ambiguous, just enough to paper over this. But I'm going to oppose naming the GUC inaccurately based on a hoped-for future development project. Another way to paper over the difference that would be to call this max_parallel_workers_per_operation. Then we can document that an operation is a Gather node, and in the future we could document that it's now a statement. However, if we pick a name like this, then we're sort of implying that this GUC will control DDL, too. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: