On Mar 31, 2006, at 9:29 PM, Tom Lane wrote:
"Matthew T. O'Connor" <matthew@xxxxxxxx> 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.
True.
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...)
The problem with that is unless I missed a change in 8.1, autovac
knows absolutely nothing about when manual vacuums have been run. To
do that I'm pretty sure we'd need a catalog table that captured the
statistic counts on each table when vacuum ran (and ideally an XID
and a timestamp, too). If we end up with some kind of dirty page
bitmap that might remove the need for that.
Even if tweaking the thresholds did work you still can't do it at a
per-database level. It doesn't seem unreasonable to support different
autovac settings at the database level.
--
Jim C. Nasby, Database Architect decibel@xxxxxxxxxxx
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
