Peter Schuller wrote:
> Actually, while on the topic:
>
> > date: 2007-09-10 13:58:50 -0400; author: alvherre; state: Exp; lines: +6 -2;
> > Remove the vacuum_delay_point call in count_nondeletable_pages, because we hold
> > an exclusive lock on the table at this point, which we want to release as soon
> > as possible. This is called in the phase of lazy vacuum where we truncate the
> > empty pages at the end of the table.
>
> 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.
> I.e., is this enough that, even without the .4 bug, one should not
> really consider VACUUM ANALYZE non-blocking with respect to other
> transactions?
You should consider it non-blocking.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
