Re: Choosing parallel_degree
От | Robert Haas |
---|---|
Тема | Re: Choosing parallel_degree |
Дата | |
Msg-id | CA+TgmoYe5eDhjRodo3uOtVFGiDWwO2zGUp_mDHeSxuEqq-jS_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Choosing parallel_degree (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Choosing parallel_degree
|
Список | 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 по дате отправления: