pg_autovacuum bug and feature request - Mailing list pgsql-hackers

From Vincent van Leeuwen
Subject pg_autovacuum bug and feature request
Date
Msg-id 20030704174016.GA24859@md2.mediadesign.nl
Whole thread Raw
Responses Re: pg_autovacuum bug and feature request  ("Matthew T. O'Connor" <matthew@zeut.net>)
List 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 by date:

Previous
From: Michael Brusser
Date:
Subject: Hitting the nfile limit
Next
From: Tom Lane
Date:
Subject: Re: Hitting the nfile limit