Re: limiting hint bit I/O
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org
Date: 2011-01-14T19:13:51Z
Lists: 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