Re: postgresql.conf.sample ordering for IO, worker related GUCs

Hi,

On 2025-01-31 18:21:54 -0500, Andres Freund wrote:
> On January 31, 2025 5:22:43 PM EST, Robert Treat <rob(at)xzilla(dot)net> wrote:
> >On Fri, Jan 31, 2025 at 10:25 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >>
> >> Hi,
> >>
> >> On 2025-01-30 21:24:05 -0500, Andres Freund wrote:
> >> > On January 30, 2025 8:55:36 PM EST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> > >Andres Freund <andres(at)anarazel(dot)de> writes:
> >> > >> While working on polishing the AIO patchset, I was trying to figure out where
> >> > >> to fit the new GUCs. So far I had a new "top-level" #--- style section named
> >> > >> "WIP AIO GUC docs" which I suspect you all won't let me get away with.
> >> > >> There is an existing (sub-)section which already has a few related GUCs and
> >> > >> could fit AIO related ones.
> >> > >
> >> > >I think the normal theory for postgresql.conf.sample is that it should
> >> > >match the organization of config.sgml. What are you planning there?
> >> >
> >> > Pretty much the same. I.e. I'm thinking that the worker stuff should be it's
> >> > own subsection and that the existing IO parameters should be moved to either
> >> > a new subsection or a new top level section. But I'm wondering how others
> >> > think it should be structured...
> >>
> >> Here are draft changes for the minimal thing I think we should do.
> >>
> >> I don't really know what to do about the "IO" abbreviation. The other sections
> >> un-abbreviate abbreviations, but I suspect that Input/Output will be less
> >> informative than IO to most...
> >>
> >> I still wonder if we instead ought to create a top-level "IO" section instead
> >> of leaving it under "Resource Usage". How many IOs we combine, how
> >> aggressively we flush unflushed data, etc only kinda fits into the resource
> >> usage category.
> >>
> >
> >+1 from me, though I did pause on whether it should be called
> >"background workers" rather than "worker processes", but I think this
> >is the right direction.
>
> +1 for the patch as-is, or my suggestion to make it a top level section?

I pushed the patch as I had it, save for replacing IO with I/O where
appropriate. If we want to go for a larger restructuring in the future, this
won't make it harder, and perhaps even a little simpler.

Greetings,

Andres Freund