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
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 |