| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | leiyanliang(at)highgo(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16972: parameter parallel_leader_participation's category problem |
| Date: | 2021-04-21 11:37:37 |
| Message-ID: | CALj2ACWkRHjbS+PFHwReX4fKbgxc7FWtj7ycmnN34X5mWRUOrw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Apr 21, 2021 at 4:15 PM Michael Paquier <michael(at)paquier(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Move-parallel_leader_participation-to-Resource-Co.patch | application/octet-stream | 7.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2021-04-21 12:39:30 | BUG #16976: server crash when deleting via a trigger on a foreign table |
| Previous Message | Michael Paquier | 2021-04-21 10:44:58 | Re: BUG #16972: parameter parallel_leader_participation's category problem |