Re: Automatic free space map filling

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: Automatic free space map filling
Дата
Msg-id 1141376884.3327.58.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на Re: Automatic free space map filling  ("Matthew T. O'Connor" <matthew@zeut.net>)
Ответы Re: Automatic free space map filling  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
> Are you running 8.1?  If so, you can use autovacuum and set per table 
> thresholds (read vacuum aggressivly) and per table cost delay settings 
> so that the performance impact is minimal.  If you have tried 8.1 
> autovacuum and found it unhelpful, I would be curious to find out why.

Yes, I'm running 8.1, and I've set up per table auto-vacuum settings :-)
And I lowered the general thresholds too. Generally autovacuum is very
useful from my POV, and in particular the per table settings are so.

But the problem I have is not the performance impact of the vacuum
itself, but the impact of the long running transaction of vacuuming big
tables. I do have big tables which are frequently updated and small
tables which are basically queue tables, so each inserted row will be
updated a few times and then deleted. Those queue tables tend to get
huge unvacuumable dead space during any long running transaction, and
vacuum on the big tables is such a long running transaction. And I have
a few of them, and one is in particular very busy (a task table, all
activities go through that one).

Now when the queue tables get 1000 times dead space compared to their
normal size, I get performance problems. So tweaking vacuum cost delay
doesn't buy me anything, as not vacuum per se is the performance
problem, it's long run time for big tables is.

Cheers,
Csaba.




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

Предыдущее
От: Lukas Smith
Дата:
Сообщение: Re: column order in GROUP BY
Следующее
От: George Weaver
Дата:
Сообщение: Re: [NOVICE] pg_config --pgxs