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)
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 |