On Tue, Dec 27, 2011 at 1:24 PM, Jeff Davis <pg...@j-davis.com> wrote: > 3. Attack hint bits problem.
A large number of problems would go away if the current hint bit system could be replaced with something that did not require writing to the tuple itself. FWIW, moving the bits around seems like a non-starter -- you're trading a problem with a much bigger problem (locking, wal logging, etc). But perhaps a clog caching strategy would be a win. You get a full nibble back in the tuple header, significant i/o reduction for some workloads, crc becomes relatively trivial, etc etc. My first attempt at a process local cache for hint bits wasn't perfect but proved (at least to me) that you can sneak a tight cache in there without significantly impacting the general case. Maybe the angle of attack was wrong anyways -- I bet if you kept a judicious number of clog pages in each local process with some smart invalidation you could cover enough cases that scribbling the bits down would become unnecessary. Proving that is a tall order of course, but IMO merits another attempt. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers