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 <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
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
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
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: