Alvaro Herrera <[EMAIL PROTECTED]> 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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
