Re: another autovacuum scheduling thread
| От | David Rowley |
|---|---|
| Тема | Re: another autovacuum scheduling thread |
| Дата | |
| Msg-id | CAApHDvoBZu-oEsRV+QzVACkQCdGxm5Q7RSs_q+J+G27EObS+zA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: another autovacuum scheduling thread (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: another autovacuum scheduling thread
|
| Список | pgsql-hackers |
On Wed, 12 Nov 2025 at 09:25, Sami Imseih <samimseih@gmail.com> wrote: > The thing I’m hoping to address is something I’ve seen many times in practice. > Autovacuum workers can get stuck on specific large or slow tables, and when > that happens, users often end up running manual vacuums on those tables > just to keep things moving for the smaller/faster vacuumed tables. > > Now, I am not so sure any type of autovacuum prioritization could actually > help in these cases. What does help is adding more autovacuum workers. Thanks for explaining. I think the scoring system in Nathan's patch helps with this as any smaller table which are neglected continue to bloat, and because they're smaller, the score will increase more quickly, and eventually they'll have a higher score than the larger tables. I think the situation you're talking about is when *all* autovacuum workers are busy with large tables and no workers remaining to deal with the now-higher-scoring smaller tables and they bloat severely or statistics become wildly outdated as a result. I'm aware of that problem. It seems to happen mostly when large tables are busy receiving an anti-wraparound vacuum. I'm not sure what to do about it, but I don't think changing the scoring system is the right thing. Maybe we can have it configurable so that 1 worker can be configured to not work on tables above a given size, so there's at least 1 worker that is less likely to be tied up for extended periods of time. I don't know if that's a good idea, and also don't know what realistic values for "given size" are. David
В списке pgsql-hackers по дате отправления: