From: Chris Browne <cbbrowne@acm.org>
Subject: Re: Autovacuum / full vacuum
Date: Tue, 17 Jan 2006 13:40:46 -0500
Organization: cbbrowne Computing Inc
Lines: 31
Message-ID: <604q42elzl.fsf@dba2.int.libertyrms.com>
References: <dqigaf$1b98$1@news.hub.org>
	<20060117145649.GE21092@phlogiston.dyndns.org>
	<608xteerfh.fsf@dba2.int.libertyrms.com>
	<20060117173046.GA4296@surnet.cl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux)
Cancel-Lock: sha1:Vpmknl2KaUjQKfHlAx1h1EfvIUc=
To: pgsql-performance@postgresql.org

alvherre@alvh.no-ip.org (Alvaro Herrera) writes:
> Chris Browne wrote:
>> ajs@crankycanuck.ca (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