From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: crash-safe visibility map, take three |
Date: | 2011-01-07 18:28:54 |
Message-ID: | 7502A9A8-B5C8-4C82-8843-4AE0F638D207@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(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... ;)
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2011-01-07 18:29:52 | Re: DISCARD ALL ; stored procedures |
Previous Message | Joel Jacobson | 2011-01-07 18:10:34 | obj_unique_identifier(oid) |