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 по дате отправления: