> > > On Nov 12, 2025, at 5:10 PM, Sami Imseih <[email protected]> wrote: > > > > > >> > >> I do think re-prioritization is worth considering, but IMHO we should > leave > >> it out of phase 1. I think it's pretty easy to reason about one round > of > >> prioritization being okay. The order is completely arbitrary today, so > how > >> could ordering by vacuum-related criteria make things any worse? > > > > While it’s true that the current table order is arbitrary, that > arbitrariness > > naturally helps distribute vacuum work across tables of various sizes > > at a given time > > > > The proposal now is by design forcing all the top bloated table, that > > will require more I/O to vacuum to be vacuumed at the same time, > > by all workers. Users may observe this after they upgrade and wonder > > why their I/O profile changed and perhaps slowed others non-vacuum > > related processing down. They also don't have a knob to go back to > > the previous behavior. > > > > Of course, this behavior can and will happen now, but with this > > prioritization, we are forcing it. > > > > Is this a concern? > > It’s still possible to tune the cost delay, the number of autovacuum > workers, etc - if someone needs to manage too much autovacuum I/O > concurrency and dialing it back down a little bit. I think that’s sufficient >
Yes, the need to tune a/v for I/O( lower cost limit, higher cost delay ) will likely be greater with this change. -- Sami
