Re: BUG #16972: parameter parallel_leader_participation's category problem
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: leiyanliang@highgo.com, pgsql-bugs@lists.postgresql.org
Date: 2021-04-21T11:37:37Z
Lists: pgsql-bugs
Attachments
- v2-0001-Move-parallel_leader_participation-to-Resource-Co.patch (application/octet-stream) patch v2-0001
On Wed, Apr 21, 2021 at 4:15 PM Michael Paquier <michael@paquier.xyz> wrote: > > 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. +1. Attached v2. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
Commits
-
doc: Move parallel_leader_participation to its correct category
- 1599e7b37512 14.0 landed