On Thu, May 16, 2019 at 3:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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
