Re: Rename max_parallel_degree?

On Tue, May 3, 2016 at 11:42 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
>>> Magnus seems OK with the way things are.
>>> Peter wants to change either the fact that it is 0-based or the fact
>>> that it is called degree, but is OK with either.
>>> Tom doesn't like "degree" and also thinks anything called degree
>>> should 1-based, but it sounds like he's more interested in changing
>>> the first thing than the second one
>>> Bruce and JD seemed to like degree -> workers.
>>> JD also suggested another option that nobody else endorsed.
>>> Alvaro suggested another option that nobody else endorsed.
>>>
>>> Does anyone else want to vote?
>>
>> I think the way it is currently in HEAD seems easy to correlate how the
>> feature works, but may be it appears to me that way because I am involved
>> from long time with this implementation.   I also think one can easily
>> confused among max_parallel_workers and max_worker_processes, so if we want
>> to change, my vote goes with changing the default of max_parallel_degree to
>> 1 (as suggested by Peter G.).
>
> I'd like to put my +1 against making the current GUCs with their
> current names 1-based, rather than 0-based. Doing anything else like
> giving them new names seems like reinventing the wheel.
>
> My reasoning is that the only gripe that I understand against the
> current names is that the "degree" term appears not to be aligned with
> what other databases do.
>
> I think that actual rows / (degree+1) might get confusing for people,
> such as in the following EXPLAIN ANALYZE output.
>
>          Workers Launched: 2
>          ->  Partial Aggregate  (cost=96331.21..96331.22 rows=1
> width=8) (actual time=584.297..584.297 rows=1 loops=3)
>                ->  Parallel Seq Scan on a  (cost=0.00..85914.57
> rows=4166657 width=0) (actual time=1.566..347.091 rows=3333333
> loops=3)
>
> The above would make more sense with max_parallel_degree=3.
>
> I also think that the parallel query, at its best will have the
> workers working hard for their tuples. In such cases the main process
> will be helping out much more, and the more it helps the more a
> 1-based degree makes sense. Also I can't stretch my imagination enough
> to imagine how any other database can handle worker tuples any
> differently than us... Surely their main process/thread must marshal
> worker's tuples the same as what we do? And if they use a 1-based
> degree for that, then surely we can too.

OK, my reading of this thread is that there is a consensus is to
redefine max_parallel_degree=1 as "no parallelism" and
max_parallel_degree>1 as "parallelism using a leader plus N-1
workers", and along with that, to keep the names unchanged.  However,
I don't think I can get that done before beta1, at least not without a
serious risk of breaking stuff.  I can look at this post-beta1.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company