Re: limiting hint bit I/O

On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Um, yeah, I think you're having a problem keeping all the ideas straight
>>> ;-).  The argument about forensics has to do with how soon we're willing
>>> to freeze tuples, ie replace the XID with a constant.  Not about hint
>>> bits.
>
>> Those things are related, though.  Freezing sooner could be viewed as
>> an alternative to hint bits.
>
> Freezing sooner isn't likely to reduce I/O compared to hint bits.  What
> that does is create I/O that you *have* to execute ... both in the pages
> themselves, and in WAL.

It depends on which way you tilt your head - right now, we rewrite
each table 3x - once to populate, once to hint, and once to freeze.
If the table is doomed to survive long enough to go through all three
of those, then freezing is better than hinting. Of course, that's not
always the case, but people keep complaining about the way this shakes
out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company