Re: Idea for getting rid of VACUUM FREEZE on cold pages - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date
Msg-id 4C08D1AC0200002500031F4A@gw.wicourts.gov
Whole thread Raw
In response to Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> I just see a lot of cost caused by this "safety range". I yet
>> have to see its real value, other than "feel good".
> 
> Jan, you don't know what you're talking about.  I have repeatedly
> had cases where being able to look at xmin was critical to
> understanding a bug.  I *will not* hold still for a solution that
> effectively reduces min_freeze_age to zero.
In my experience with my own environment, I can honestly say that
it's clear that not freezing tuples quickly adds more cost than
running with cassert on.  If we had to run in production with one or
the other, I would definitely choose cassert from a performance
perspective; which one would do more to find bugs?  Why do we view
them so differently?
-Kevin


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Did we really want to force an initdb in beta2?
Next
From: Robert Haas
Date:
Subject: Re: Exposing the Xact commit order to the user