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.

Reply via email to