Re: crash-safe visibility map, take three

On Fri, Jan 7, 2011 at 1:28 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On Jan 5, 2011, at 8:10 PM, Robert Haas wrote:
>> On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh <jesper(at)krogh(dot)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