Re: Rename max_parallel_degree?
От | Josh berkus |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | 57509894.9080507@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Rename max_parallel_degree?
Re: Rename max_parallel_degree? |
Список | pgsql-hackers |
On 06/02/2016 01:08 PM, David G. Johnston wrote: > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus <josh@agliodbs.com > <mailto:josh@agliodbs.com>>wrote: > > On 06/02/2016 08:53 AM, Tom Lane wrote: > > Josh berkus <josh@agliodbs.com <mailto:josh@agliodbs.com>> writes: > >> On 06/02/2016 04:58 AM, Robert Haas wrote: > >>> Well, I think we could drop node, if you like. I think parallel > >>> wouldn't be good to drop, though, because it sounds like we want a > >>> global limit on parallel workers also, and that can't be just > >>> max_workers. So I think we should keep parallel in there for all of > >>> them, and have max_parallel_workers and > >>> max_parallel_workers_per_gather(_node). The reloption and the Path > >>> struct field can be parallel_workers rather than parallel_degree. > > > >> So does that mean we'll rename it if you manage to implement a parameter > >> which controls the number of workers for the whole statement? > > > > That would fit in as something like max_parallel_workers_per_statement. > > ETOOMANYKNOBS > > I'm trying to think of some way we can reasonably automate this for > users ... > > > Are you referring to right now or if we move the goal posts to making > this a per-statement reservation? I was assuming that we would have *both* per-operation and per-statement limits. I can see reasons for having both, I can see why power users would want both, but it's going to be overwhelming to casual users. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
В списке pgsql-hackers по дате отправления: