On 5/31/16 8:48 PM, Robert Haas wrote:
On Tue, May 31, 2016 at 5:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvhe...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to