Re: Autovacuum / full vacuum

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Autovacuum / full vacuum
Date: 2006-01-18 16:54:21
Message-ID: 60d5ipcw8y.fsf@dba2.int.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

mind(at)bi(dot)lt ("Mindaugas") writes:
>> >> 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.
>>
>> > 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.
>>
>> You sure? It's not supposed to, and watching a database-wide
>> vacuum with "select * from pg_locks" doesn't look to me like it
>> ever has locks on more than one table (plus the table's indexes and
>> toast table).
>
> Are there some plans to remove vacuum altogether?

I don't see that on the TODO list...

http://www.postgresql.org/docs/faqs.TODO.html

To the contrary, there is a whole section on what functionality to
*ADD* to VACUUM.
--
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/finances.html
"There are two types of hackers working on Linux: those who can spell,
and those who can't. There is a constant, pitched battle between the
two camps."
--Russ Nelson (Linux Kernel Summary, Ver. 1.1.75 -> 1.1.76)

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Alvaro Herrera 2006-01-18 16:55:21 Re: Autovacuum / full vacuum
Previous Message mark 2006-01-18 16:50:17 Re: Suspending SELECTs