pg_autovacuum bug and feature request

From: Vincent van Leeuwen <pgsql(dot)spam(at)vinz(dot)nl>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pg_autovacuum bug and feature request
Date: 2003-07-04 17:40:16
Message-ID: 20030704174016.GA24859@md2.mediadesign.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Brusser 2003-07-04 17:40:23 Hitting the nfile limit
Previous Message Bruno Wolff III 2003-07-04 17:30:45 Compile error in current cvs (~1230 CDT July 4)