Re: Autovacuum Improvements

Поиск
Список
Период
Сортировка
От Alban Hertroys
Тема Re: Autovacuum Improvements
Дата
Msg-id 45ABA6C2.5000006@magproductions.nl
обсуждение исходный текст
Ответ на Re: Autovacuum Improvements  ("Pavan Deolasee" <pavan@enterprisedb.com>)
Список pgsql-general
Pavan Deolasee wrote:
> Simon Riggs wrote:
>> On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote:
>>> Christopher Browne wrote:
>>>
>>>> Seems to me that you could get ~80% of the way by having the simplest
>>>> "2 queue" implementation, where tables with size < some threshold get
>>>> thrown at the "little table" queue, and tables above that size go to
>>>> the "big table" queue.
>>>>
>>>> That should keep any small tables from getting "vacuum-starved."
>>
>
> This is exectly what I am trying, two process autovacuum and a GUC to
> seperate small tables.
>
> In this case, one process takes up vacuuming of the small tables and
> other process vacuuming of the remaining tables as well as Xid
> avoidance related vacuuming. The goal is to avoid starvation of small
> tables when a large table is being vacuumed (which may take
> several hours) without adding too much complexity to the code.

Would it work to make the queues push the treshold into the direction of
the still running queue if the other queue finishes before the still
running one? This would achieve some kind of auto-tuning, but that is
usually tricky.

For example, what if one of the queues got stuck on a lock?

--
Alban Hertroys
alban@magproductions.nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
   7500 AK Enschede

// Integrate Your World //

В списке pgsql-general по дате отправления:

Предыдущее
От: Alban Hertroys
Дата:
Сообщение: Re: check table existence...
Следующее
От: Aleksander Kmetec
Дата:
Сообщение: Re: Unpredicatable behavior of volatile functions used