On Wed, 2010-12-22 at 10:59 -0500, Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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