Re: AutoVacuum on demand? - Mailing list pgsql-general

From Richard Broersma Jr
Subject Re: AutoVacuum on demand?
Date
Msg-id 959766.99103.qm@web31812.mail.mud.yahoo.com
Whole thread Raw
In response to Re: AutoVacuum on demand?  (Glen Parker <glenebob@nwlink.com>)
List pgsql-general
> Hmm, I thought this would be obvious.  Vacuumdb just issues "VACUUM"
> commands.
>
> I would like the get the functionality if autovacuum so that I don't
> waste cycles on tables that don't really need vacuuming.  However, we've
> had bad luck letting autovacuum run on its own terms, so we've reverted
> to the old nightly vacuums.
>
> Since our nightly window of relative inactivity continues to shrink, I'd
> like to vacuum/analyze only the tables that autovacuum thinks need it,
> all at once, and only when I tell it to (via cron).
>
> Make more sense?

If you could instruct auto_vacuum not to vacuum certain tables would that accomplish what you
wanted in place of having auto_vacuum enable/dis-abled from a cron?

http://www.postgresql.org/docs/8.1/interactive/maintenance.html#AUTOVACUUM
Besides the base threshold values and scale factors, there are three more parameters that can be
set for each table in pg_autovacuum. The first, pg_autovacuum.enabled, can be set to false to
instruct the autovacuum daemon to skip that particular table entirely. In this case autovacuum
will only touch the table when it vacuums the entire database to prevent transaction ID
wraparound. The other two parameters, the vacuum cost delay (pg_autovacuum.vac_cost_delay) and the
vacuum cost limit (pg_autovacuum.vac_cost_limit), are used to set table-specific values for the
Cost-Based Vacuum Delay feature.

Regards,

Richard Broersma Jr.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: LIKE OPERATOR cardinality estimation
Next
From: Richard Huxton
Date:
Subject: Re: blocking function in PL/Python