On Tue, May 31, 2016 at 3:35 PM, Robert Haas <robertmh...@gmail.com> wrote:
> 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. 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). David J.
