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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Дата
Msg-id 20140409141922.GJ4161@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins