Re: another autovacuum scheduling thread
| От | Jeremy Schneider |
|---|---|
| Тема | Re: another autovacuum scheduling thread |
| Дата | |
| Msg-id | AFC199A4-423E-4B9C-A6CF-F8EE2163B2C5@ardentperf.com обсуждение исходный текст |
| Ответ на | Re: another autovacuum scheduling thread (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: another autovacuum scheduling thread
|
| Список | 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 autovacuumI/O concurrency and dialing it back down a little bit. I think that’s sufficient -Jeremy
В списке pgsql-hackers по дате отправления: