Attached is an updated version of the 'hint bit cache'. What's changed: *) 'bucket' was changed to 'page' everywhere *) rollup array is now gets added during 'set', not the 'get' (pretty dumb the way it was before -- wasn't really dealing with non-commit bits yet) *) more source comments, including a description of the cache in the intro *) now caching 'invalid' bits.
I went back and forth several times whether to store invalid bits in the same cache, a separate cache, or not at all. I finally settled upon storing them in the same cache which has some pros and cons. It makes it more or less exactly like the clog cache (so I could copy/pasto some code out from there), but adds some overhead because 2 bit addressing is more expensive than 1 bit addressing -- this is showing up in profiling...i'm upping the estimate of cpu bound scan overhead from 1% to 2%. Still fairly cheap, but i'm running into the edge of where I can claim the cache is 'free' for most workloads -- any claim is worthless without real world testing though. Of course, if tuple hint bits are set or PD_ALL_VISIBLE is set, you don't have to pay that price. What's not: *) Haven't touched any satisfies routine besides HeapTupleSatisfiesMVCC (should they be?) *) Haven't pushed the cache data into CacheMemoryContext. I figure this is the way to go, but requires extra 'if' on every cache 'get'. *) Didn't abstract the clog bit addressing macros. I'm leaning on not doing this, but maybe they should be. My reasoning is that there is no requirement for hint bit cache that pages should be whatever block size is, and I'd like to reserve the ability to adjust the cache page size independently. I'd like to know if this is a strategy that merits further work...If anybody has time/interest that is. It's getting close to the point where I can just post it to the commit fest for review. In particular, I'm concerned if Tom's earlier objections can be satisfied. If not, it's back to the drawing board... merlin
hbache_v5.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
