On Thu, 2012-11-15 at 22:21 -0500, Tom Lane wrote: > We aren't pressed for flag bits particularly. I think the main > attraction of this idea is precisely to reduce unnecessary page dirties, > and so that leads me to suggest a variant: keep the four bits defined as > now, but do not attempt to set XMIN_INVALID or XMAX_COMMITTED unless the > page is already dirty. This would make it a straight-up trade of more > clog consultation for fewer page dirties.
Sounds reasonable. > > Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced > > in the visibility map patch, apparently as a way to know when to clear > > the VM bit when doing an update. It was then also used for scans, which > > showed a significant speedup. But I wonder: why not just use the > > visibilitymap directly from those places? > > Added contention for access to the visibility map pages would be a > problem. Can you think of a reasonable (or worst-case) test scenario that would illustrate this problem? Would I need a many-core box to actually test this? Also, what locks do you expect to be contended? The buffer header lock while pinning the VM page? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers