Re: crash-safe visibility map, take three - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: crash-safe visibility map, take three
Date
Msg-id 7502A9A8-B5C8-4C82-8843-4AE0F638D207@nasby.net
Whole thread Raw
In response to Re: crash-safe visibility map, take three  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: crash-safe visibility map, take three  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Jan 5, 2011, at 8:10 PM, Robert Haas wrote:
> On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh <jesper@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
instructionoperation? 

This is sounding like premature optimization... ;)
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Chris Browne
Date:
Subject: Re: [COMMITTERS] pgsql: Implement remaining fields of information_schema.sequences view
Next
From: Stephen Frost
Date:
Subject: Re: DISCARD ALL ; stored procedures