Re: autovacuum

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: "Enzo Daddario" <enzo(at)pienetworks(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: autovacuum
Date: 2006-01-26 14:41:08
Message-ID: 5001.71.40.140.99.1138286468.squirrel@mail.tocr.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Legit concern. However one of the things that autovacuum is supposed to
do is not vacuum tables that don't need it. This can result in an overal
reduction in vacuum overhead. In addition, if you see that autovacuum is
firing off vacuum commands during the day and they are impacting your
response time, then you can play with the vacuum cost delay settings that
are design to throttle down the IO impact vacuum commands can have. In
addition if you use 8.1, you can set per table thresholds, per table
vacuum cost delay settings, and autovacuum will respect the work done by
non-autovacuum vacuum commands. Meaning that if you manually vacuum
tables at night during a maintenance window, autovacuum will take that
into account. Contrib autovacuum couldn't do this.

Hope that helps. Real world feed-back is always welcome.

Matt

> I am concerned with the impact autovacuum of table(s) would have on
> regular DB activity.
>
> With our current DB's the majority of tables have either a low number of
> updates or a large number of inserts (which I believe should not be a
> problem), however, a small number of tables have an extremely high
> number of updates (up to 150 000)

In response to

  • autovacuum at 2006-01-23 05:07:21 from Enzo Daddario

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2006-01-26 15:06:29 Re:
Previous Message Brian A. Seklecki 2006-01-26 12:41:30 Re: Database Clustering

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-01-26 15:34:22 Re: Cleaning up the INET/CIDR mess
Previous Message William ZHANG 2006-01-26 14:25:40 Re: GRANT/REVOKE: Allow column-level privileges