Re: lazy vacuum sleeps with exclusive lock on table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: lazy vacuum sleeps with exclusive lock on table
Дата
Msg-id 26424.1183077245@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: lazy vacuum sleeps with exclusive lock on table  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: lazy vacuum sleeps with exclusive lock on table  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> What I'm requesting here is that the sleep in count_nondeletable_pages()
> be removed and that change backpatched to 8.2 and 8.1.

Are you sure that that is, and always will be, the only sleep in that
part of the code path?

Seems like it might be better to adjust the cost_delay parameters after
we acquire exclusive lock.  I'm not sure dialing them all the way back
to zero is a good idea, but certainly we could make them more
aggressive.

>> Seems like VACUUM shouldn't try just once to get the lock.

> We don't know how many pages we can truncate until after we have
> acquired the exclusive lock and examined the pages in question, scanning
> backwards from the end of the table.

We could estimate this during the forward scan.  The backward scan is
still necessary to see if anyone has inserted tuples after we looked at
a page, but certainly a page that VACUUM failed to empty will still be
nonempty, so we can determine an upper bound on how much might be
truncatable.

However, that's an orthogonal concern and should probably be discussed
separately.
        regards, tom lane


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

Предыдущее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: lazy vacuum sleeps with exclusive lock on table
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: AutoVacuum Behaviour Question