Re: another autovacuum scheduling thread
От | Jeremy Schneider |
---|---|
Тема | Re: another autovacuum scheduling thread |
Дата | |
Msg-id | 20251008164057.6bceb9ed@ardentperf.com обсуждение исходный текст |
Ответ на | Re: another autovacuum scheduling thread (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: another autovacuum scheduling thread
|
Список | pgsql-hackers |
On Wed, 8 Oct 2025 12:06:29 -0500 Sami Imseih <samimseih@gmail.com> wrote: > > One risk I see with this approach is that we will end up autovacuuming > tables that also take the longest time to complete, which could cause > smaller, quick-to-process tables to be neglected. > > It’s not always the case that the oldest tables in terms of (M)XID age > are also the most expensive to vacuum, but that is often more true > than not. I think an approach of doing largest objects first actually might work really well for balancing work amongst autovacuum workers. Many years ago I designed a system to backup many databases with a pool of workers and used this same simple & naive algorithm of just reverse sorting on db size, and it worked remarkably well. If you have one big thing then you probably want someone to get started on that first. As long as there's a pool of workers available, as you work through the queue, you can actually end up with pretty optimal use of all the workers. -Jeremy
В списке pgsql-hackers по дате отправления: