Re: BUG #16972: parameter parallel_leader_participation's category problem - Mailing list pgsql-bugs

From Bharath Rupireddy
Subject Re: BUG #16972: parameter parallel_leader_participation's category problem
Date
Msg-id CALj2ACUr--FC3ac7LiZABtX6FaeLqfwbyi+2m629wSPYiZZX5Q@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16972: parameter parallel_leader_participation's category problem  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #16972: parameter parallel_leader_participation's category problem  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
On Wed, Apr 21, 2021 at 8:16 AM Michael Paquier <michael@paquier.xyz> wrote:
> So I agree that your patch is adapted, even postgresql.conf.sample
> gets that right.  Something that your patch makes worse is the
> alphabetical order of the parameters listed in this section
> (backend_flush_after can be also blamed here), so I'll go reorder this
> sub-area a bit while on it, except if somebody objects.

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.

So, -1 for reordering.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #16972: parameter parallel_leader_participation's category problem
Next
From: RekGRpth
Date:
Subject: Re: BUG #16974: memory leak