On Wed, Dec 19, 2012 at 11:49 AM, Pavan Deolasee
<pavan.deolasee@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