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
|
| Список | 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 по дате отправления: