Re: Rename max_parallel_degree?

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Rename max_parallel_degree?
Дата
Msg-id CAKFQuwa6K0AqxZv-NYdBLQvUeZHVKtOgd+BJgpan5SwnfuSiBg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rename max_parallel_degree?  (Josh berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus <josh@agliodbs.com> wrote:
On 06/02/2016 01:08 PM, David G. Johnston wrote:
> On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus <josh@agliodbs.com
> <mailto:josh@agliodbs.com>>wrote:
>
>     On 06/02/2016 08:53 AM, Tom Lane wrote:
>     > Josh berkus <josh@agliodbs.com <mailto: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?​

I was assuming that we would have *both* per-operation and per-statement
limits.  I can see reasons for having both, I can see why power users
would want both, but it's going to be overwhelming to casual users.


​Got that.  The only problem on that front with the current setup is that right now we are saying: "at most use 3 of the 8 available processes": i.e., we tie ourselves to a fixed number when I think a better algorithm would be: "on/off/auto - default auto" and we detect at runtime whatever values we feel are most appropriate based upon the machine we are running on.  If the user doesn't like our choices they can specify their own values.  But the only specified values in the configurations would be those placed there automatically by the user.  If value isn't specified but is required it gets set at startup and can be seen in pg_settings.

David J.

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

Предыдущее
От: Josh berkus
Дата:
Сообщение: Re: Rename max_parallel_degree?
Следующее
От: Corey Huinker
Дата:
Сообщение: Let file_fdw access COPY FROM PROGRAM