Re: Choosing parallel_degree

On Wed, Apr 6, 2016 at 10:49 PM, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
wrote:
>
> On 06/04/2016 07:38, Amit Kapila wrote:
> > On Tue, Apr 5, 2016 at 11:55 PM, Julien Rouhaud
> >>
> >> 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.
> >
>
> Ok. Isn't there also some considerations about forcing replanning of
> prepared statements using the table for instance?
>

not sure, what you mean by that.

>
> >>
> >> 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.
> >
>
> Agreed, changed in attached v8 (including fix for previous mail).
>

+ /*
+ * Limit the degree of parallelism logarithmically based on the size
+ * of the relation. This probably needs to be a good deal more
+ * sophisticated, but we need something here for now.

I think your pgindent run has changed something unrelated. It is not
preferred to change unrelated things in patch.

Other than that, patch looks good and I have marked it as Ready For
Committer. Hope, we get this for 9.6.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com