Re: How much do the hint bits help?

On Wed, 2010-12-22 at 10:59 -0500, Tom Lane wrote:
> Heikki Linnakangas  writes:
> > 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 think it's far more likely that that could be acceptable than the
> radical method of removing hint bits altogether.

I haven't argued to remove them, just have an option to not set them.

> I have not looked into what's wrong with Merlin's test case, but my
> thinking about it goes like this: we know that contention for buffer
> lookup is significant at high loads, despite the facts that the accesses
> are distributed across a lot of independently-usable buffers and we've
> done much work to partition the lookup locks.  If we remove hint bits
> and thereby force an access to clog for every tuple touch, we can expect
> that the contention for clog access will be comparable to the worst case
> for buffer access contention ... except that in many cases, it will be
> distributed across far fewer pages and so the actual interference rate
> will be far higher.  This will make our past experiences with "context
> swap storms" look like a day at the beach.

I think you're right, but I also think there are other ways we could
optimise that other than hint bits. 

For example, the single item cache might be changed, or we might
buffer/batch clog updates, or we might use a hash table of known aborted
transactions etc.

As Merlin points out, we don't have much evidence for their value or
lack of value, so we need a parameter to allow wide scale testing.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services