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.
regards, tom lane