pg_autovacuum bug and feature request

Поиск
Список
Период
Сортировка
От Vincent van Leeuwen
Тема pg_autovacuum bug and feature request
Дата
Msg-id 20030704174016.GA24859@md2.mediadesign.nl
обсуждение исходный текст
Ответы Re: pg_autovacuum bug and feature request  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-hackers
Hi,

I've been using pg_autovacuum for a couple of weeks now, and have noticed one
weird little bug: sometimes the daemon calculates it used a negative amount of
time for the last vacuum it did, and waits no time at all before checking if
it needs to run anything again. Sample output:

2411 All DBs checked in: -717533400 usec, will sleep for 30 secs.

The 30 secs is only because I ran it like this:
pg_autovacuum -d 2 -s 30 -S 0 -t 250 -T 0.01 -U postgres

I'm using PostgreSQL 7.3.2 on Debian Linux, kernel 2.4.21-rc3.


Also, I'd like to see a way to tell pg_autovacuum which tables it should
monitor. I understand most setups would like to have all tables monitored, but
on our setup pg_autovacuum is wasting most of it's time (and a fair amount of
serverload) vacuuming some large tables (several GB's of data, the vacuums
regularly take half an hour per table or something in the very rough vicinity)
which doesn't give a large win in performance anyway, while it should be
focusing it's efforts on a few intensively used small tables, where frequent
vacuums are a much larger win for performance. I vacuum everything nightly
anyway, so those large tables can be totally ignored by pg_autovacuum in my
setup. As you can see from the weird -t and -T parameters I already tried to
make it favor those smaller tables (which get about the same amount of updates
as the large tables), but I'm not quite sure I'm doing it the right way.


Regards,

Vincent van Leeuwen
Media Design - http://www.mediadesign.nl/


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

Предыдущее
От: Michael Brusser
Дата:
Сообщение: Hitting the nfile limit
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Hitting the nfile limit