On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > Also, if extra WAL-logging is really worrisome, may be we should again > seriously reconsider my idea of *not* clearing the bit at HOT update. > My apologies for repeating myself. But that seems very important in a > steady system when almost every update is a HOT update. So you don't > clear the bit at HOT update and so don't need to set it back either, > thus saving two WAL activity. You definitely don't need any vacuum in > this case if pruning keeps reclaiming dead space at appropriate time > and make it available for the next update. More so, IOS still works > great. Why is this so bad ?
It's bad because then sequential scans will return wrong answers, unless we also rip out the optimization that uses PD_ALL_VISIBLE as an excuse to skip all visibility checks for the page. That optimization is worth a significant amount of performance. It's also bad because then vacuum won't visit the page, and it really should. It's much better to have vacuum prune the page in the background than to have some query do it in the foreground, although the latter is still better than not doing it at all. We could potentially have two or three bits per page to suit these different needs: (1) page can benefit from a vacuum, (2) page is safe for IOS purposes, and (3) page is safe for seqscan purposes. But I think that might be overengineering. IMHO, the goal here should be to have some method of setting the visibility map, in some set of circumstances, outside of vacuum. Figuring out which set of circumstances is appropriate is the hard part. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
