Re: Vacuum, Freeze and Analyze: the big picture

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Vacuum, Freeze and Analyze: the big picture
Дата
Msg-id 20130530200709.GJ14029@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Vacuum, Freeze and Analyze: the big picture  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On 2013-05-30 12:18:29 -0700, Josh Berkus wrote:
> 
> > If we have reason to vacuum the relation we do it at
> > vacuum_freeze_table_age, not only at autovacuum_max_freeze_age. The
> > difference is that the latter triggers a vacuum, while the former only
> > changes a partial vacuum into a full one.
> > 
> > Calling that behaviour unconditionally worse is, err, interesting...
> 
> *overall* it's better.  But as far as FREEZE itself is concerned, it's
> worse.

I am not trying to give you a hard time, but I really can't follow. In
<8.3 we only froze tuples that were older than vacuum_freeze_min_age,
just as today (although the default was higher then than today). 100mio
transactions is long enough that you almost guaranteedly be in a
different checkpoint cycle when freezing than when initially writing the
tuple's buffer. So independent of the time the buffer is frozen (be it
a) we always scan the whole relation, b) we have a partial vacuum
upgraded to a full one due to vacuum_freeze_table_age c) an anti
wraparound vacuum) we will usually write a buffer multiple times.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Freezing without write I/O