From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Autovacuum / full vacuum |
Date: | 2006-01-17 18:40:46 |
Message-ID: | 604q42elzl.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
alvherre(at)alvh(dot)no-ip(dot)org (Alvaro Herrera) writes:
> Chris Browne wrote:
>> ajs(at)crankycanuck(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-17 19:32:52 | Re: Autovacuum / full vacuum |
Previous Message | Andrew Sullivan | 2006-01-17 18:13:50 | Re: Autovacuum / full vacuum |