Re: BUG #16972: parameter parallel_leader_participation's category problem

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #16972: parameter parallel_leader_participation's category problem
Дата
Msg-id YIACKgzEThp6J81I@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #16972: parameter parallel_leader_participation's category problem  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: BUG #16972: parameter parallel_leader_participation's category problem  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список pgsql-bugs
On Wed, Apr 21, 2021 at 09:15:23AM +0530, Bharath Rupireddy wrote:
> If we arrange only the "Asynchronous Behaviour" subsection in
> alphabetical order, I think the order may not be maintained in case of
> new GUCs that may get added there. Because all the other subsections
> are unordered and there's no note of maintaining the order as such.
> And, it looks like the relevant GUCs are grouped for better
> readability. For instance, all "parallelism", "io_concurrency", "jit_"
> related GUCs are together. Developers tend to add the new GUCs in
> relevant areas.

That's up to the committers adding them to be careful, but I of course
agree that the context is important.  IMV, we can do a slightly better
organization in "Asynchronous Behaviour".  First, backend_flush_after
is independent, and could just be first.

parallel_leader_participation can also be moved after
max_parallel_workers without impacting the readability nor impacting
the set of parallel-ish parameters grouped together.
--
Michael

Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: postgres has no spinlock support on riscv rv64imafdc
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: BUG #16972: parameter parallel_leader_participation's category problem