Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
Дата
Msg-id 4A844AA80200002500029A7F@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-performance
Alvaro Herrera <alvherre@commandprompt.com> wrote:
> Jeff Davis wrote:
>
>> Why aren't we more opportunistic about freezing tuples? For
>> instance, if we already have a dirty buffer in cache, we should be
>> more aggressive about freezing those tuples than freezing tuples on
>> disk.
>
> The most widely cited reason is that you lose forensics data.
> Although they are increasingly rare, there are still situations in
> which the heap tuple machinery messes up and the xmin/xmax/etc
> fields of the tuple are the best/only way to find out what happened
> and thus fix the bug.  If you freeze early, there's just no way to
> know.

Although I find it hard to believe that this is compelling argument in
the case where an entire table or database is loaded in a single
database transaction.

In the more general case, I'm not sure why this argument applies here
but not to cassert and other diagnostic options.  It wouldn't surprise
me to find workloads where writing data three times (once for the
data, once for hint bits, and once to freeze the tid) affects
performance more than cassert.

-Kevin

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )