On Tue, May 31, 2016 at 3:19 PM, Tom Lane <t...@sss.pgh.pa.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.
