Re: VACUUM ANALYZE blocking both reads and writes to a table
От | Peter Schuller |
---|---|
Тема | Re: VACUUM ANALYZE blocking both reads and writes to a table |
Дата | |
Msg-id | 20080630154318.GB15756@hyperion.scode.org обсуждение исходный текст |
Ответ на | Re: VACUUM ANALYZE blocking both reads and writes to a table (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: VACUUM ANALYZE blocking both reads and writes to a
table
|
Список | pgsql-performance |
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? 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? (I realize various exclusive locks are taken for short periods of time even for things that are officially declared non-blocking; the question is whether this falls into this category.) -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
Вложения
В списке pgsql-performance по дате отправления: