Re: hint bit cache v5

On Wed, May 11, 2011 at 10:38 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> One thing I need to test is how much benefit you'll see with wider records.

The results are a bit better, around 25% using a similar methodology
on ~ 1k wide records.

> I think I'm gonna revert the change to cache invalid bits. I just
> don't see hint bits as a major contributor to dead tuples following
> epic rollbacks

what I meant to say here was, I don't see hint bit i/o following
rollbacks as a major issue. Point being, I don't see much use in
optimizing management of INVALID tuple bits beyond what is already
done.

Anyways, demonstrating a 'good' case is obviously not the whole story.
But what are the downsides? There are basically two:

1) tiny cpu penalty on every heap fetch
2) extremely widely dispersed (in terms of transaction id) unhinted
tuples can force the cache to refresh every 100 tuples in the absolute
worst case. A cache refresh is a 100 int sort and a loop.

For '1', the absolute worst case I can come up with, cpu bound scans
of extremely narrow records, the overall cpu usage goes up around 1%.
'2' seems just impossible to see in the real world -- and if it does,
you are also paying for lots of clog lookups all the way through the
slru, and you are having i/o and other issues on top of it. Even if
all the stars align and it does happen, all the tuples get hinted and
dirtied anyways so it will only happen at most once on that particular
set of data.

merlin