On Wed, 2010-12-22 at 15:30 +0200, Heikki Linnakangas wrote:
> > I would vote to put this into 9.1 as a non-default option at restart,
> > opening the door to other features which hint bits are frustrating.
> > People can then choose between those features and the "power of hint
> > bits". I think many people would choose db block checksums.
>
> Making it optional would add some ifs in the critical paths, possibly
> making it slower.
Hardly. A server-start parameter is going to be constant during
execution and branch prediction will just snuff that away to nothing.
> My gut feeling is that a reasonable compromise is to set hint bits like
> we do today, but don't mark the page as dirty when only hint bits are
> set. That way you get the benefit of hint bits for tuples that are
> frequently accessed and stay in buffer cache. But you don't spend any
> extra I/O to set them. I'd really like to see a worst-case scenario
> benchmark of a patch that does that.
That sounds great, but still prevents block checksums and that is a very
valuable feature for robustness. This isn't a discussion about hint
bits, its a discussion about opening the way for other features.
ISTM there are other ways of optimising any clog issues that may remain,
so clutching to this ancient optimisation has no further benefit for me.
Merlin's idea seems to me to be original, useful *and* reasonable.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services