Re: less expensive pg_buffercache on big shmem

On Tue, Sep 20, 2016 at 7:43 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> On 09/02/2016 11:01 AM, Robert Haas wrote:
>>
>> On Fri, Sep 2, 2016 at 8:49 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>>
>>> On 2016-09-02 08:31:42 +0530, Robert Haas wrote:
>>>>
>>>> I wonder whether we ought to just switch from the consistent method to
>>>> the semiconsistent method and call it good.
>>>
>>>
>>> +1. I think, before long, we're going to have to switch away from having
>>> locks & partitions in the first place. So I don't see a problem relaxing
>>> this. It's not like that consistency really buys you anything... I'd
>>> even consider not using any locks.
>>
>> I think we certainly want to lock the buffer header, because otherwise
>> we might get a torn read of the buffer tag, which doesn't seem good.
>> But it's not obvious to me that there's any point in taking the lock
>> on the buffer mapping partition; I'm thinking that doesn't really do
>> anything unless we lock them all, and we all seem to agree that's
>> going too far.
>
> +1 from me to only locking the buffer headers. IMHO that's perfectly fine
> for the purpose of this extension.

So, I think we have agreement on the way forward here, but what we
don't have is a committable patch. I'm willing to commit one before
the end of this CommitFest if somebody produces one RSN; otherwise,
this is going to have to go into the "Returned with Feedback" bucket.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company