On Sat, Sep 28, 2019 at 1:36 PM Jeff Davis <pgsql@j-davis.com> 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 interfering with other uses of
> worker processes.
I don't think that would work as well. Some day we might have another
class of worker processes with its own independent limit, and then
this terminology would get confusing. It makes sense to say that you
can have up to 10 worker processes of which at most 4 can be used for
parallel query and at most 3 can be used for logical replication, but
it doesn't make nearly as much sense to say that you can have up to 10
worker processes of which 6 can't be used for parallel query and of
which 7 can't be used for logical application. That leaves, uh, how
many?
> 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.
Here again, I imagine that in the future we might have various
different worker classes that need to share the total number of
workers, but not necessarily via a hard partition. For example, you
could sensible say that there are 3 purposes for workers and 10
workers, and no single purpose can consume more than 4 workers. Even
though 4 * 3 > 10, it's a completely reasonable configuration. The
early bird gets the juiciest worm, and the late bird doesn't starve to
death. Even a more extreme configuration where you limit each purpose
to, say, 7 workers could be reasonable. Here there is a risk of
starvation, but you may know that in your environment it's not likely
to last for very long.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company