1. First things first: vacuum cannot delete tuples that are still
visible to any old running transactions. You might have some very long
queries or transactions that prevent it from cleaning properly:
select * from pg_stat_activity where xact_start < now()-interval '10 minutes';
2. On 8.3 and earlier servers with large tables, it's critical that
your max_fsm_pages and max_fsm_relations are tuned properly. Failing
that, autovacuum will permanently leak space that can only be fixed
with a VACUUM FULL (which will take an exclusive lock and run for a
very long time)
PostgreSQL version 8.4 addressed this problem, but for the
unfortunate, you have to follow the tuning advice here:
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server#autovacuum_max_fsm_pages.2C_max_fsm_relations
On Tue, Sep 27, 2011 at 08:08, Royce Ausburn <royce.ml@inomial.com> wrote:
> I've noticed that the same tables seem to be auto vacuum'd over and over again… Some of the tables are a bit
surprisingin that they're updated semi-regularly, but not enough (I'd think) to warrant an autovacuum every few
minutes…Is this unusual?
Maybe they're just auto-analyze processes? Those get triggered on
insert-only tables too, when vacuum normally wouldn't run.
> Perhaps unrelated: I've done some digging around and happened across a nightly task doing:
> select pg_stat_reset()
AFAIK (but I could be wrong), vacuum uses a separate set of statistics
not affected by pg_stat_reset.
Regards,
Marti
