On Thu, May 2, 2019 at 5:10 AM Robert Haas <robertmh...@gmail.com> wrote: > On Wed, May 1, 2019 at 12:50 PM Tom Lane <t...@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
