Re: Removing PD_ALL_VISIBLE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing PD_ALL_VISIBLE
Date
Msg-id 19021.1353964248@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Sun, 2012-11-25 at 22:30 -0500, Tom Lane wrote:
>> Another possibly important point is that reducing the number of
>> pin/unpin cycles for a given VM page might actually hurt the chances of
>> it being found in shared buffers, because IIRC the usage_count is bumped
>> once per pin/unpin.

> If doing a bunch of simple key lookups using an index, then the root of
> the index page is only pinned once per query, but we expect that to stay
> in shared buffers. I see the VM page as about the same: one pin per
> query (or maybe a couple for large tables).

Hmmm ... that seems like a valid analogy.  I may be worried about
nothing as far as this point goes.

> Do you still think I need a shared lock here or something? If so, then
> index-only scans have a pretty big problem right now, too.

There's still the issue of whether the IOS code is safe in machines with
weak memory ordering.  I think that it probably is safe, but the
argument for it in the current code comment is wrong; most likely, a
correct argument has to depend on read/write barriers associated with
taking snapshots.  I think what you ought to do is work through that,
fix the existing comment, and then see whether the same argument works
for what you want to do.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: WIP json generation enhancements
Next
From: Alvaro Herrera
Date:
Subject: Re: support for LDAP URLs