To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Peter Schuller <peter.schuller@infidyne.com>,
	pgsql-performance@postgresql.org
Subject: Re: VACUUM ANALYZE blocking both reads and writes to a table 
In-reply-to: <20080630162306.GA18252@alvh.no-ip.org> 
References: <20080630145903.GA15197@hyperion.scode.org>
	<20080630152515.GF10311@alvh.no-ip.org>
	<20080630154318.GB15756@hyperion.scode.org>
	<20080630162306.GA18252@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Mon, 30 Jun 2008 12:23:06 -0400"
Date: Mon, 30 Jun 2008 15:00:40 -0400
Message-ID: <3064.1214852440@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Peter Schuller wrote:
>> Even with the fix the lock is held. Is the operation expected to be
>> "fast" (for some definition of "fast") and in-memory, or is this
>> something that causes significant disk I/O and/or scales badly with
>> table size or similar?

> It is fast.

Well, it's *normally* fast.  In a situation where there are a whole lot
of empty pages at the end of the table, it could be slow.  That's
probably not very likely on a heavily used table.  One should also note
that

(1) The only way vacuum will be able to obtain an exclusive lock in the
first place is if there are *no* other transactions using the table at
the time.

(2) If it's autovacuum we're talking about, it will get kicked off the
table if anyone else comes along and wants a conflicting lock.

			regards, tom lane