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.
It sure isn't. Also, I think that we might actually want to add an additional GUC to prevent the parallel query system from consuming the entire pool of processes established by max_worker_processes. If you're doing anything else with worker processes on your system, you might well want to say, well, it's OK to have up to 20 worker processes, but at most 10 of those can be used for parallel queries, so that the other 10 are guaranteed to be available for whatever other stuff I'm running that uses the background process facility. It's worth remembering that the background worker stuff was originally invented by Alvaro to allow users to run daemons, not for parallel query. So I think in the long run we should have three limits: 1. Cluster-wide limit on number of worker processes for all purposes (currently, max_worker_processes). 2. Cluster-wide limit on number of worker processes for parallelism (don't have this yet). 3. Per-operation limit on number of worker processes for parallelism (currently, max_parallel_degree). Whatever we rename, there needs to be enough semantic space between #1 and #3 to allow for the possibility - I think the very likely possibility - that we will eventually also want #2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers