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.
--
Thomas Munro
https://enterprisedb.com
