Re: Do we need so many hint bits?
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Merlin Moncure <mmoncure@gmail.com>
Date: 2012-11-16T06:44:23Z
Lists: pgsql-hackers
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