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.
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.
My mind started going here too...though the question is whether you need a reserved pool or whether we apply some algorithm if (max_parallel + max_other > max_cluster). That algorithm could be configurable (i.e., target ratio 20:10 where 20+10 == max_cluster).
