Re: Rename max_parallel_degree?

On 01/06/16 17:27, Jim Nasby wrote:
> On 5/31/16 8:48 PM, Robert Haas wrote:
>> On Tue, May 31, 2016 at 5:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>>>> Robert Haas wrote:
>>>>> I just want to point out that if we change #1, we're breaking
>>>>> postgresql.conf compatibility for, IMHO, not a whole lot of benefit.
>>>>> I'd just leave it alone.
>>>
>>>> We can add the old name as a synonym in guc.c to maintain
>>>> compatibility.
>>>
>>> I doubt this is much of an issue at this point; max_worker_processes has
>>> only been there a release or so, and surely there are very few people
>>> explicitly setting it, given its limited use-case up to now. It will be
>>> really hard to change it after 9.6, but I think we could still get away
>>> with that today.
>>
>> max_worker_processes was added in 9.4, so it's been there for two
>> releases, but it probably is true that few people have set it.
>> Nevertheless, I don't think there's much evidence that it is a bad
>> enough name that we really must change it.
>
> ISTM that all the confusion about parallel query would go away if the
> setting was max_parallel_assistants instead of _workers. It's exactly
> how parallel query works: there are helpers that *assist* the backend in
> executing the query.
>
> The big downside to "assistants" is it breaks all lexical connection to
> max_worker_processes. So what if we change that to
> max_assistant_processes? I think "assistant" and "worker" are close
> enough in meaning for "stand alone" uses of BG workers so as not to be
> confusing, and I don't see any options for parallelism that are any
> clearer.

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.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services