Re: Choosing parallel_degree

On Tue, Apr 5, 2016 at 11:55 PM, Julien Rouhaud <julien.rouhaud@dalibo.com> wrote:
>
> On 05/04/2016 06:19, Amit Kapila wrote:
> >
> > Few more comments:
> >
> > 1.
> > @@ -909,6 +909,17 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } |
> > UNLOGGED ] TABLE [ IF NOT EXI
> >
> > </varlistentry>
> >
> >     <varlistentry>
> > +    <term><literal>parallel_degree</> (<type>integer</>)</term>
> > +    <listitem>
> > +
> > <para>
> > +     Sets the degree of parallelism for an individual relation.  The
> > requested
> > +     number of workers will be
> > limited by <xref
> > +     linkend="guc-max-parallel-degree">.
> > +     </para>
> > +    </listitem>
> > +   </varlistentry>
> >
> > All other parameters in this category are supportted by Alter table
> > command as well, so I think this parameter should also be supported by
> > Alter Table command (for both SET and RESET variants).
> >
>
> I don't quite understand.  With the patch you can use parallel_degree in
> either CREATE or ALTER table (SET and RESET) statements.

>

No issues then.

>  Considering
> documentation, the list of storage parameters only appears in
> create_table.sgml, alter_table.sgml pointing to it.
>
> In alter_table.sgml, I didn't comment the lock level needed to modify
> parallel_degree since it requires an access exclusive lock for now.
> While thinking about it, I think it's safe to use a share update
> exclusive lock but I may be wrong.  What do you think?
>

We require to keep AccessExclusiveLock for operations which can impact Select operation which I think this operation does, so lets retain AccessExclusiveLock for now.  If somebody else thinks, we should not bother about Selects, then we can change it.

> > 2.
> > +"Number of parallel processes per executor node wanted for this relation.",
> >
> > How about
> > Number of parallel processes that can be used for this relation per
> > executor node.
> >
>
> I just rephrased what was used for the max_parallel_degree GUC, which is:
>
> "Sets the maximum number of parallel processes per executor node."
>
> I find your version better once again, but should we keep some
> consistency between them or it's not important?
>

I think consistency is good, but this is different from max_parallel_degree, so I would prefer to use something on lines of what I have mentioned.