Re: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal

Greg Stark  writes:
> On Sun, Nov 14, 2010 at 8:52 PM, Josh Berkus  wrote:
>> For example, imagine if the hint bits were moved to a separate per-table
>> bitmap outside the table instead of being stored with each row, as the
>> current FSM is.

> How many times do we have to keep going around the same block?

> We *already* have separate bitmap outside the table for transaction
> commit bits. It's the clog.

> The only reason the hint bits exist is to cache that so we don't need
> to do extra I/O to check tuple visibility. If the hint bits are moved
> outside the table then they serve no purpose whatsover. Then you have
> an additional I/O to attempt to save an additional I/O.

Well, not quite.  The case this could improve is index-only scans:
you could go (or so he hopes) directly from the index to the hint
bits given the TID stored by the index.  A clog lookup is not possible
without XMIN & XMAX, which we do not keep in index entries.

But I'm just as skeptical as you are about this being a net win.
It'll pessimize too much other stuff.

Josh is ignoring the proposal that is on the table and seems actually
workable, which is to consult the visibility map during index-only
scans.  For mostly-static tables this would save trips to the heap for
very little extra I/O.  The hard part is to make the VM reliable, but
that is not obviously harder than making separately-stored hint bits
reliable.
		regards, tom lane