On 5/31/16 8:48 PM, Robert Haas wrote:
> On Tue, May 31, 2016 at 5:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Alvaro Herrera <alvherre@2ndquadrant.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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
