Re: another autovacuum scheduling thread

>
> > On Nov 12, 2025, at 5:10 PM, Sami Imseih <samimseih(at)gmail(dot)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
greater with this change.

--
Sami