> 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
autovacuumI/O concurrency and dialing it back down a little bit. I think that’s sufficient
-Jeremy
