Re: Rename max_parallel_degree?

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Rename max_parallel_degree?
Дата
Msg-id CAKFQuwbJwf26X0JFOWMLZYpaUobmDVEsp3YDvNhHtM8YDNbaKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rename max_parallel_degree?  (Josh berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus <josh@agliodbs.com> wrote:
On 06/02/2016 08:53 AM, Tom Lane wrote:
> Josh berkus <josh@agliodbs.com> writes:
>> On 06/02/2016 04:58 AM, Robert Haas wrote:
>>> Well, I think we could drop node, if you like.  I think parallel
>>> wouldn't be good to drop, though, because it sounds like we want a
>>> global limit on parallel workers also, and that can't be just
>>> max_workers.  So I think we should keep parallel in there for all of
>>> them, and have max_parallel_workers and
>>> max_parallel_workers_per_gather(_node).  The reloption and the Path
>>> struct field can be parallel_workers rather than parallel_degree.
>
>> So does that mean we'll rename it if you manage to implement a parameter
>> which controls the number of workers for the whole statement?
>
> That would fit in as something like max_parallel_workers_per_statement.

ETOOMANYKNOBS

I'm trying to think of some way we can reasonably automate this for
users ...

​Are you referring to right now or if we move the goal posts to making this a per-statement reservation?​

Oh, and how does one measure 0.7​18... of a knob?

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: XTM & parallel search
Следующее
От: Josh berkus
Дата:
Сообщение: Re: Rename max_parallel_degree?