Message-ID: <4315675a0ea69af857d282f35072254ee73c61d6.camel@j-davis.com>
Subject: Re: max_parallel_workers question
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: Sat, 28 Sep 2019 10:36:45 -0700
In-Reply-To: 
 <CA+TgmoZLaOUUfHv1S+ueUCyazHrR-YE6jSZ9mZiwgGcM7eDi-w@mail.gmail.com>
References: <d040a1144e0127a49e335d1244a4de102a2a443b.camel@j-davis.com>
	 <CA+TgmoZLaOUUfHv1S+ueUCyazHrR-YE6jSZ9mZiwgGcM7eDi-w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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, PGC_SIGHUP seems most appropriate.

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 interfering with other uses of
worker processes.

Another option would be to make it two pools, one for parallel workers
and one for everything else, and each one would be controlled by a
PGC_POSTMASTER setting. But it seems like some thought went into trying
to share the pool of workers[1], so I assume there was a good reason
you wanted to do that.

Regards,
	Jeff Davis

[1] If I'm reading correctly, it uses both lock-free code and
intentional overflow.