On Sat, Sep 28, 2019 at 12:10:53AM -0400, Robert Haas wrote:
> On Fri, Sep 27, 2019 at 8:07 PM Jeff Davis wrote:
> > The current docs for max_parallel_workers start out:
> >
> > "Sets the maximum number of workers that the system can support for
> > parallel operations..."
> >
> > In my interpreta
On Sat, Sep 28, 2019 at 1:36 PM Jeff Davis wrote:
> In that case, PGC_SIGHUP seems most appropriate.
Yeah.
> It also might make more sense to rename it to reserved_worker_processes
> and invert the meaning. To me, that would be more clear that it's
> designed to prevent parallel query from inter
On Sat, 2019-09-28 at 00:10 -0400, Robert Haas wrote:
> I intended it to mean "the entire cluster." Basically, how many
> workers out of max_worker_processes are you willing to use for
> parallel query, as opposed to other things. I agree that PGC_USERSET
> doesn't make any sense.
In that case, PG
On Fri, Sep 27, 2019 at 8:07 PM Jeff Davis wrote:
> The current docs for max_parallel_workers start out:
>
> "Sets the maximum number of workers that the system can support for
> parallel operations..."
>
> In my interpretation, "the system" means the entire cluster, but the
> max_parallel_workers
The current docs for max_parallel_workers start out:
"Sets the maximum number of workers that the system can support for
parallel operations..."
In my interpretation, "the system" means the entire cluster, but the
max_parallel_workers setting is PGC_USERSET. That's a bit confusing,
because two di
