On Wed, May 11, 2011 at 10:38 AM, Merlin Moncure <mmonc...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers