Re: auto vacuuming

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Gourish Singbal <gourish(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: auto vacuuming
Date: 2006-04-01 03:29:01
Message-ID: 6991.1143862141@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> I think the closest approximation of disabling autovacuum on a per
> database basis is to connect to the database in question and perform:
> update pg_autovacuum set enabled = 'false';

Not really gonna help unless you insert a row into pg_autovacuum for
each table in the database.

As I just commented in another reply, I don't actually believe in the
value of disabling autovac entirely --- it should at least be able to
fire when you are risking XID wraparound. What could make sense is to
push the thresholds up to very large values, such that autovac won't
fire until you've forgotten manual vacuums for a very long time.
And that you can already do on a per-database basis, using ALTER
DATABASE SET. (Or at least, it *should* work to do that; if the autovac
process fails to absorb per-db values for its GUC variables, then we
ought to fix it. I'm too lazy to test it right now...)

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Joshua D. Drake 2006-04-01 03:32:46 Re: auto vacuuming
Previous Message Tom Lane 2006-04-01 03:17:47 Re: auto vacuuming