Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Date
Msg-id 20140409141922.GJ4161@awork2.anarazel.de
Whole thread Raw
In response to Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-04-09 10:09:44 -0400, Tom Lane wrote:
> The resource managers are interesting to bring up in this context.
> That mechanism didn't exist when PrivateRefCount was invented.
> Is there a way we could lay off the work onto the resource managers?
> (I don't see one right at the moment, but I'm under-caffeinated still.)

Yea, that's something I've also considered, but I couldn't come up with
a performant and sensibly complicated way to do it.
There's some nasty issues with pins held by different ResourceOwners and
such, so even if we could provide sensible random access to check for
existing pins, it wouldn't be a simple thing.

It's not unreasonable to argue that we just shouldn't optimize for
several pins held by the same backend for the same and always touch the
global count. Thanks to resource managers the old reason for
PrivateRefCount, which was the need to be able cleanup remaining pins in
case of error, doesn't exist anymore.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Next
From: Tom Lane
Date:
Subject: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins