On Fri, 2008-09-12 at 11:21 +0200, Csaba Nagy wrote: > On Fri, 2008-09-12 at 09:38 +0100, Simon Riggs wrote: > > If you request a block, we check to see whether there is a lookaside > > copy of it prior to the tuple removals. We then redirect the block > > request to a viewpoint relation's block. Each viewpoint gets a separate > > relfilenode. We do the switcheroo while holding cleanup lock on block. > > Wouldn't it make sense to also have a hint bit on the pages which are > copied away ?
There is no need for hint bit (and one bit would not be enough anyway, as we may need to keep multiple versions) A LSN of last row-removal (VACUUM or HOT-pruning) would serve as a hint to start digging around in hash tables. It seems though , that you may have to look into several disk snapshots to find the page you need. > Then instead of looking up a hash table, you first would > look up that bit, and if not set you won't look up the hash table at > all. Then when you clean up the "lookaside copies" you clear those bits > too... > > That would probably perform somewhat better for reading than always > looking up a potentially big hash table, and the cost of setting the > hint is probably a lot less than copying away the page in the first > place. Resetting the hint bit might be a bit more expensive. > > Cheers, > Csaba. > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
