On Wed, Dec 19, 2012 at 9:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > If we start generating a lot of useless WAL activity and I/O as > a result of thrashing the all-visible bit, it won't be so tolerable > anymore.
What if we wrap that into the WAL generated by HOT prune itself ? Would that address your concerns for extra WAL logging ? I also suggested doing it conditionally to avoid contention on the VM buffer. (I actually wonder why we WAL-log set operation at all except for HS to be able to do IOS, but thats a topic for separate thread may be) 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 ? I haven't forgotten your complaints about changed meaning of the bit, but I tried to explain that we can read it in a slightly different way and still show it as an invariant. > > I think my core point still stands: the way that HOT pruning is done now > is an artifact of having wanted to shoehorn it into the system with > minimum changes. Which was reasonable at the time given the > experimental status of the feature, but now it's time to reconsider. > ISTM that you already have concret ideas about what are those places where HOT prune would be more effective. My worry is changing anything there is going to be a lot trickier and will require heavy testing. Our initial work has served us well so far. Of course, I've no problem changing that if its going to benefit users. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
