Re: Rename max_parallel_degree?

On Tue, May 31, 2016 at 3:35 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

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