On Mon, Mar 12, 2012 at 5:28 PM, Robert Haas <robertmh...@gmail.com> wrote:
> In other words, we'd entirely avoid needing to make mxacts crash-safe, > and we'd avoid most of the extra SLRU lookups that the current > implementation requires; they'd only be needed when (and for as long > as) the locked tuple was not yet all-visible. The current implementation only requires additional lookups in the update/check case, which is the case that doesn't do anything other than block right now. Since we're replacing lock contention with physical access contention even the worst case situation is still better than what we have now. Please feel free to point out worst case situations and show that isn't true. I've also pointed out how to avoid overhead of making mxacts crash safe when the new facilities are not in use, so I don't see problems with the proposed mechanism. Given that I am still myself reviewing the actual code. So those things are not something we need to avoid. My feeling is that overwriting xmin is a clever idea, but arrives too late to require sensible analysis in this stage of the CF. It's not solving a problem, its just an alternate mechanism and at best an optimisation of the mechanism. Were we to explore it now, it seems certain that another person would observe that design were taking place and so the patch should be rejected, which would be unnecessary and wasteful. I also think it would alter our ability to diagnose problems, not least the normal test that xmax matches xmin across an update. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
