On Fri, Jan 7, 2011 at 1:28 PM, Jim Nasby <j...@nasby.net> wrote: > On Jan 5, 2011, at 8:10 PM, Robert Haas wrote: >> On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh <jes...@krogh.cc> wrote: >>> Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit >>> serve? >> >> If we modify a page on which PD_ALL_VISIBLE isn't set, we don't >> attempt to update the visibility map. In theory, this is an important >> optimization to reduce contention on the visibility map page, since >> there are something like 64K heap pages per visibility map page. In >> practice, I'm not sure in what workloads it matters or by how much. > > What specific locking are you worried about? The page locks themselves? Isn't > changing the bit essentially a single instruction operation? > > This is sounding like premature optimization... ;)
I'm not quite invested enough in this to get worried about it, but if I were, I'd probably start with the buffer content lock, and move on to the buffer header spinlock and the buf mapping locks. Changing the bit is a single instruction once you've got the page pinned and locked, but that's not free. (And even if you could hypothetically figure out some clever lock-free algorithm to avoid some of this work, there's still going to be cache line contention, which is quite expensive as it turns out. See the relatively recent discussions of why our backend startup cost is so high.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
