Re: Choosing parallel_degree
От | Simon Riggs |
---|---|
Тема | Re: Choosing parallel_degree |
Дата | |
Msg-id | CANP8+jJQPsuMRCBfS+Bxd8W0ZrcFBm8t0ddrWxvyqfETDdUSjA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Choosing parallel_degree (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Choosing parallel_degree
|
Список | pgsql-hackers |
On 14 September 2016 at 14:48, Robert Haas <robertmhaas@gmail.com> wrote: > 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. OK. Will post on new thread. > 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. You're quoting that without context from the line above, which is "get_tablespace_io_concurrency" -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: