> On Nov 12, 2025, at 5:10 PM, Sami Imseih <samimseih@gmail.com> 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
