On Tuesday, May 31, 2016, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
Josh berkus <josh@agliodbs.com> writes:
> On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
>> But the distinction between parallel workers and backends that can
>> participate in parallel query does need to be user-visible. Worker
>> processes are a commodity (i.e. the user must consider
>> max_worker_processes).
> It's still WAY simpler to understand "max_parallel is the number of
> parallel workers I requested".
> Any system where you set it to 2 and get only 1 worker on an idle system
> is going to cause endless queries on the mailing lists.
I really think that a GUC named "max_parallel_workers", which in fact
limits the number of workers and not something else, is the way to go.
What is your opinion on the internal name for this? Leave it as "degree"? Skimming the patch the number of times that "parallel_degree - 1" is used would concern me.
I would also probably reword "Parallel workers are taken from the pool...": changing parallel with the word additional. "Additional workers are taken from the pool...".
I'm tending to think we are using the word "parallel" too often and that selective removal would be better. "Sets the maximum number of workers (i.e., processes) that can be used to perform an operation." An introductory section on parallelism can lay out the framework and the concept of parallelism. Sentences like the one above can assume that the reader understands that they work in parallel if the operation allows and there are workers available. The same observation can be applied to "leader". When more than one process is involved a leader is chosen. This is general background to cover upfront. Elsewhere just talk of workers and let the leader be implied. No need to keep repeating "including the leader". In many ways leader is an implementation detail the user doesn't care about. The only impact is that 2 is not twice as good as 1 due to overhead - whatever form that overhead takes.
The change from two to three for the default sneaked in there...
David J.