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)
Ответы Re: VACUUM ANALYZE blocking both reads and writes to a table  (Alvaro Herrera)
Список pgsql-performance
Дерево обсуждения
VACUUM ANALYZE blocking both reads and writes to a table  (Peter Schuller, )
 Re: VACUUM ANALYZE blocking both reads and writes to a table  (Alvaro Herrera, )
  Re: VACUUM ANALYZE blocking both reads and writes to a table  (Peter Schuller, )
  Re: VACUUM ANALYZE blocking both reads and writes to a table  (Peter Schuller, )
   Re: VACUUM ANALYZE blocking both reads and writes to a table  (Alvaro Herrera, )
    Re: VACUUM ANALYZE blocking both reads and writes to a table  (Tom Lane, )
     Re: VACUUM ANALYZE blocking both reads and writes to a table  (Alvaro Herrera, )
      Re: VACUUM ANALYZE blocking both reads and writes to a table  (Peter Schuller, )
    Re: VACUUM ANALYZE blocking both reads and writes to a table  (Alvaro Herrera, )
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 <>'
Key retrieval: Send an E-Mail to 
E-Mail:  Web: http://www.scode.org


Вложения

В списке pgsql-performance по дате отправления:

Предыдущее
От: Mark Roberts
Дата:
Сообщение: Re: Does max size of varchar influence index size
Следующее
От: John Beaver
Дата:
Сообщение: Re: sequence scan problem