Re: Rename max_parallel_degree?
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh berkus <josh@agliodbs.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Peter Geoghegan <pg@heroku.com>, Robert Haas <robertmhaas@gmail.com>,
Noah Misch <noah@leadboat.com>, David Rowley <david.rowley@2ndquadrant.com>,
Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-05-31T19:37:52Z
Lists: pgsql-hackers
On Tue, May 31, 2016 at 3:19 PM, Tom Lane <tgl@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.