Re: Rename max_parallel_degree?

On 4 May 2016 at 15:12, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, May 2, 2016 at 11:47 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
>> wrote:
>> > On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>
>> To summarize the positions as I understand them:
>>
>> 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.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services