Re: VACUUM ANALYZE blocking both reads and writes to a table

Alvaro Herrera <alvherre(at)commandprompt(dot)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