Re: Rename max_parallel_degree?

On Tue, May 31, 2016 at 3:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
> > At the risk of opening another can of worms, what about renaming
> > max_worker_processes as well? It would be a good thing if that
> > had "cluster" in it somewhere, or something that indicates it's a
> > system-wide value not a per-session value. "max_workers_per_cluster"
> > would answer, though I'm not in love with it particularly.
>
> Actually, after a bit more thought, maybe "max_background_workers" would
> be a good name? That matches its existing documentation more closely:
>
> Sets the maximum number of background processes that the system
> can support. This parameter can only be set at server start. The
> default is 8.
>
> However, that would still leave us with max_background_workers as the
> cluster-wide limit and max_parallel_workers as the per-query-node limit.
> That naming isn't doing all that much to clarify the distinction.
>
>
​Node execution is serial, right?​

​I know work_mem has a provision about possibly using multiples of the
maximum in a single query...

​The per-node dynamic does seem important to at least well-document so that
when users see 3 workers on one explain node and 2 on another they aren't
left scratching their heads. We don't reserve a set number of workers
per-statement but rather they are retrieved as needed during query
execution.

I think I see the same amount of added value in tacking on 'per_cluster" as
you do in adding "additional" to get "max_additional_parallel_workers" -
though further refinement of trying to actively NOT consider a leader a
worker would support the omission of addition[al]...

If we left max_worker_processes as defining only the maximum allowed
non-parallel workers and added a new "max_cluster_workers" that would cap
the combination of both "max_worker_processes" and "max_parallel_workers"...

David J.​