Re: another autovacuum scheduling thread
| От | Sami Imseih |
|---|---|
| Тема | Re: another autovacuum scheduling thread |
| Дата | |
| Msg-id | CAA5RZ0ufYr0MPQbGy3zsKf8QQpG5KA5++jSEKGJvjNRKsG+Qzg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: another autovacuum scheduling thread (Jeremy Schneider <schneider@ardentperf.com>) |
| Список | pgsql-hackers |
> 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
greater with this change.
--
Sami
В списке pgsql-hackers по дате отправления: