Re: Rename max_parallel_degree? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Rename max_parallel_degree?
Date
Msg-id CAKFQuwZs-qvVmAekEeYQADTj7XEveJUpU8KgGL3_GL2U_fYEJg@mail.gmail.com
Whole thread Raw
In response to Re: Rename max_parallel_degree?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Rename max_parallel_degree?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, Apr 24, 2016 at 8:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:

Of course, we could make this value 1-based rather than 0-based, as
Peter Geoghegan suggested a while back.  But as I think I said at the
time, I think that's more misleading than helpful.  The leader
participates in the parallel plan, but typically does far less of the
work beneath the Gather node than the other nodes involved in the
query, often almost none.  In short, the leader is special.
Pretending that it's just another process involved in the parallel
group isn't doing anyone a favor.

​Does this apply to the extent that a value of 1 is likely worse than 0 since the leader is now tasked with accumulating but there is only one process actually working to provide the leader data?

I'm inclined to accept max_parallel_workers where a value of 0 means no parallelism and the non-zero counts indicate the number of workers in addition to the required leader.

Though that does suggest "additional" as a valid option.  Something like "max_additional_workers".  Just how overloaded is the term "worker".  If worker is understood to mean "a process which implements execution of [part of] a query plan" the word additional leaves no ambiguity as to where the leader is accounted for.

​It does significantly reduce grep-ability though :(

​max_additional_parallel_workers...

David J.

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: More inaccurate results from numeric pow()
Next
From: Julien Rouhaud
Date:
Subject: max_worker_processes missing some documentation