Re: Rename max_parallel_degree?

On 06/02/2016 09:33 PM, Peter Eisentraut wrote:
> On 6/3/16 12:21 AM, Petr Jelinek wrote:
>> On 01/06/16 17:55, David G. Johnston wrote:
>>> On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek <petr@2ndquadrant.com
>>> <mailto:petr@2ndquadrant.com>>wrote:
>>>
>>>     That GUC also controls worker processes that are started by
>>>     extensions, not just ones that parallel query starts. This is btw
>>>     one thing I don't like at all about how the current limits work, the
>>>     parallel query will fight for workers with extensions because they
>>>     share the same limit.
>>>
>>>
>>> ​Given that this models reality the GUC is doing its job.  Now, maybe we
>>> need additional knobs to give the end-user the ability to influence how
>>> those fights will turn out.
>>
>> Agreed, my point is that I think we do need additional knob.
>
> We need one knob to control how many process slots to create at server
> start, and then a bunch of sliders to control how to allocate those
> between regular connections, superuser connections, replication,
> autovacuum, parallel workers, background workers (by tag/label/group),
> and so on.

Now that's crazy talk.  I mean, next thing you'll be saying that we need
the ability to monitor this, or even change it at runtime.  Where does
the madness end?  ;-)

Seriously, you have a point here; it's maybe time to stop tackling
process management per server piecemeal.  Question is, who wants to work
on this?

--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)