force_parallel_mode uniqueness

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема force_parallel_mode uniqueness
Дата
Msg-id CAKFQuwYwKw1excZho5ULLn7ZyKfZAV=WtDy4mDjOeToLOU2R3Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: force_parallel_mode uniqueness  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
My take below is that of a user reading our documentation and our projected consistency via that document.

All of the other planner GUCs are basically, {on, off, special} with on or special the default as appropriate for the feature - since most/all features default to enabled.  While I get that the expected usage is to set this to off (which really leaves parallel mode in its default on behavior) and then reduce the parallel workers to zero to disable that runs contrary to all of the other switches listed alongside force_parallel_mode.  constraint_exclusion seems like something to be emulated here.

Also, all of the other geoq options get placed here yet max parallel degree is in an entirely different section.  I'm a bit torn on this point though since it does fit nicely in asynchronous behavior.  I think the next thought finds the happy middle.

If nothing else this option should include a link to max_parallel_degree and vice-versa.  Noting how to disable the feature in this section, if the guc semantics are not changed, would be good too.  That note would likely suffice to establish the linking term to parallel degree.  Something can be devised, even if just a see also, to link back.

David J.

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

Предыдущее
От: Euler Taveira
Дата:
Сообщение: Re: Accurate list of Keywords / Datatypes?
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Disable BLOB test in pg_dump TAP tests