Re: Rename max_parallel_degree? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Rename max_parallel_degree?
Date
Msg-id CA+TgmoaHSOQbk1Z7vRdrW+Ujg35AsuZnEm2Yn_6pWA1UPqL1Ww@mail.gmail.com
Whole thread Raw
In response to Re: Rename max_parallel_degree?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rename max_parallel_degree?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 31, 2016 at 10:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Now, this case is a little trickier.  If we called it simply
>> parallel_degree rather than max_parallel_degree, then it would have
>> the same name as the reloption.  But the reloption sets an exact
>> value, and the GUC sets a cap, which is a significant difference.
>
> The reloption does not set an exact value, according to the code:
>
>         /*
>          * Use the table parallel_degree, but don't go further than
>          * max_parallel_degree.
>          */
>         parallel_degree = Min(rel->rel_parallel_degree, max_parallel_degree);
>
> although the existing documentation for it is so vague that you
> couldn't tell from that.

True, max_parallel_degree is an overriding limit.  But the point is
that, without the reloption, you can't get lots of workers on a small
table.  The reloption lets you do that.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Performance degradation in commit ac1d794
Next
From: Robert Haas
Date:
Subject: Re: Hard to maintain duplication in contain_volatile_functions_not_nextval_walker