Skip site navigation (1) Skip section navigation (2)

Re: crash-safe visibility map, take three

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: crash-safe visibility map, take three
Date: 2011-01-08 02:59:36
Message-ID: AANLkTinThcNA==iAuhOq9rrFT63Afer0k6LeYN1pJTUu@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-01-08 03:01:17
Subject: Re: Fix for pg_upgrade migrating pg_largeobject_metadata
Previous:From: Robert HaasDate: 2011-01-08 02:51:37
Subject: Re: LOCK for non-tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group