Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? ) - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
Date
Msg-id 4A844AA80200002500029A7F@gw.wicourts.gov
Whole thread Raw
In response to Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )