Hi,
On 2019-05-15 12:01:07 +1200, Thomas Munro wrote:
> On Thu, May 2, 2019 at 5:10 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > On Wed, May 1, 2019 at 12:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > > Not strongly enough to argue about it very hard. The current behavior
> > > > is a little weird, but it's a long way from being the weirdest thing
> > > > we ship, and it appears that we have no tangible evidence that it
> > > > causes a problem in practice.
> > >
> > > I think there's nothing that fails to suck about a hardwired "+ 10".
> >
> > It avoids a performance regression without adding another GUC.
> >
> > That may not be enough reason to keep it like that, but it is one
> > thing that does fail to suck.
>
> 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).
>
> The rationale for using a different number is that this backend is
> working on behalf of multiple sessions, so you might want to give it
> some more juice, much like maintenance_work_mem.
>
> 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.
Greetings,
Andres Freund