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(at)2ndquadrant(dot)com
>>> <mailto:petr(at)2ndquadrant(dot)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)