Re: limiting hint bit I/O - Mailing list pgsql-hackers

From Robert Haas
Subject Re: limiting hint bit I/O
Date
Msg-id AANLkTik51jXVpZByLg3OjB12gieeC82sJqV0jdTPBzCP@mail.gmail.com
Whole thread Raw
In response to Re: limiting hint bit I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: limiting hint bit I/O
List pgsql-hackers
On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Determining client_encoding from client locale
Next
From: Tom Lane
Date:
Subject: Re: Database file copy