On Thu, May 16, 2019 at 3:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-05-15 12:01:07 +1200, Thomas Munro wrote:
> >> This is listed as an open item to resolve for 12. IIUC the options on
> >> the table are:
> >>
> >> 1. Do nothing, and ship with effective_io_concurrency + 10.
> >> 2. Just use effective_io_concurrency without the hardwired boost.
> >> 3. Switch to a new GUC maintenance_io_concurrency (or some better name).
> >>
> >> I vote for option 3. I have no clue how to set it, but at least users
> >> have a fighting chance of experimenting and figuring it out that way.
> >> I volunteer to write the patch if we get a consensus.
>
> > I'd personally, unsurprisingly perhaps, go with 1 for v12. I think 3 is
> > also a good option - it's easy to imagine to later use it for for
> > VACUUM, ANALYZE and the like. I think 2 is a bad idea.
>
> FWIW, I also agree with settling for #1 at this point. A new GUC would
> make more sense if we have multiple use-cases for it, which we probably
> will at some point, but not today. I'm concerned that if we invent a
> GUC now, we might find out that it's not really usable for other cases
> in future (e.g., default value is no good for other cases). It's the
> old story that inventing an API with only one use-case in mind leads
> to a bad API.
>
> So yeah, let's leave this be for now, ugly as it is. Improving it
> can be future work.
Cool, I moved it to the resolved section.
--
Thomas Munro
https://enterprisedb.com