On Wed, Apr 6, 2016 at 10:49 PM, Julien Rouhaud <julien.rouh...@dalibo.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
