Re: another autovacuum scheduling thread
| От | Sami Imseih |
|---|---|
| Тема | Re: another autovacuum scheduling thread |
| Дата | |
| Msg-id | CAA5RZ0uox-mBjkCGq+yrzh1YRsroSU-SJcmfjmCepDm+pKHM-w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: another autovacuum scheduling thread (David Rowley <dgrowleyml@gmail.com>) |
| Список | pgsql-hackers |
> > 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, That is true. > 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. Another approach will be to signal for more autovacuum workers to be spun up ( user can have a minimum and max workers ) if all workers has been processing the list for a long time ( Also not sure what the long threshold would be ). This "auto-tuning" of workers could perhaps reduce the need for manual vacuums. It will still not prevent all workers from being tied up, but maybe reduce the likelihood. -- Sami
В списке pgsql-hackers по дате отправления: