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  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Comment on GatherPath.single_copy
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Logical Replication WIP