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