Re: VACUUM ANALYZE blocking both reads and writes to a table

От: Alvaro Herrera
Тема: Re: VACUUM ANALYZE blocking both reads and writes to a table
Дата: ,
Msg-id: 20080630162306.GA18252@alvh.no-ip.org
(см: обсуждение, исходный текст)
Ответ на: Re: VACUUM ANALYZE blocking both reads and writes to a table  (Peter Schuller)
Ответы: 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)
Список: 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, )

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.


В списке pgsql-performance по дате сообщения:

От: Mark Roberts
Дата:
Сообщение: Re: Does max size of varchar influence index size
От: John Beaver
Дата:
Сообщение: Re: sequence scan problem