On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > > I'm not sure if we should set the bits in very aggressively. If we're more > aggressive about setting the bits, it also means that we have to clear the > bits more often, increasing the likelihood of contention that you were > worried about.
Well, I would rather set bits aggressively and reduce contention by changing the lock type. If HOT is working well, VACUUM will have very few things to do, but visibility map wouldn't help as much as it can unless we set the bits after pruning. Another thing I noticed is the since VACUUM tries to set the bit in the first phase, it's working only because HOT prunes DEAD tuples just before we do another scan on line pointers (which I had earlier talked about getting rid of. May be its time I do that). Otherwise, the visibility bit won't be set even though the DEAD tuples will be removed in the second scan and the rest are all LIVE tuples. So if we at all want to take out the another scan of line pointers from the first pass, we should rather push the work setting bits in the prune code. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
