Hi, On 2019-05-15 12:01:07 +1200, Thomas Munro wrote: > 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.
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
