Re: Choosing parallel_degree - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Choosing parallel_degree
Date
Msg-id CA+TgmoYe5eDhjRodo3uOtVFGiDWwO2zGUp_mDHeSxuEqq-jS_A@mail.gmail.com
Whole thread Raw
In response to Re: Choosing parallel_degree  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Choosing parallel_degree
List pgsql-hackers
On Thu, Sep 1, 2016 at 9:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> > Can I change this to a lower setting? I would have done this before
>>> > applying
>>> > the patch, but you beat me to it.
>>>
>>> I don't have a problem with reducing the lock level there, if we're
>>> convinced that it's safe.
>>
>>
>> I'll run up a patch, with appropriate comments.
>
> Attached

This should really be posted on a new thread, since it changes a bunch
of reloptions, not only parallel_workers.  I can't immediately think
of a reason why the changes wouldn't be safe, but I've failed to fully
apprehend all of the possible dangers multiple times previously, so we
should try to give everyone who might have ideas about this topic a
chance to chime in with anything we might be missing.

I do think this comment is confusing:

+ *        This value is not locked by the transaction, so this value may
+ *        be changed while a SELECT that has used these values for planning
+ *        is still executing.

I don't know what it means for "this value" to be locked, or not
locked, by the transaction.  Basically, I have no idea what this is
trying to explain.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Comment on GatherPath.single_copy
Next
From: Andres Freund
Date:
Subject: Re: Logical Replication WIP