[EMAIL PROTECTED] (Alvaro Herrera) writes: > Chris Browne wrote: >> [EMAIL PROTECTED] (Andrew Sullivan) writes: >> > On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote: >> >> hi, >> >> >> >> I'm curious as to why autovacuum is not designed to do full vacuum. I >> > >> > Because nothing that runs automatically should ever take an exclusive >> > lock on the entire database, which is what VACUUM FULL does. >> >> That's a bit more than what autovacuum would probably do... >> autovacuum does things table by table, so that what would be locked >> should just be one table. > > Even a database-wide vacuum does not take locks on more than one table. > The table locks are acquired and released one by one, as the operation > proceeds. And as you know, autovacuum (both 8.1's and contrib) does > issue database-wide vacuums, if it finds a database close to an xid > wraparound.
Has that changed recently? I have always seen "vacuumdb" or SQL "VACUUM" (without table specifications) running as one long transaction which doesn't release the locks that it is granted until the end of the transaction. -- "cbbrowne","@","acm.org" http://cbbrowne.com/info/spiritual.html "My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember." -- Scott Gilbert comp.lang.python ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
