Re: Reducing overhead of frequent table locks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reducing overhead of frequent table locks
Дата
Msg-id 21022.1305386067@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reducing overhead of frequent table locks  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 13, 2011 at 11:05 PM, Noah Misch <noah@leadboat.com> wrote:
>> Incidentally, I used the term "local lock" because I assumed fast-path locks
>> would still go through the lock manager far enough to populate the local lock
>> table.  But there may be no reason to do so.

> Oh, good point.  I think we probably WOULD need to update the local
> lock lock hash table.

I haven't read this thread closely, but the general behavior of the
backend assumes that it's very very cheap to re-acquire a lock that's
already held by the current transaction.  It's probably worth
maintaining a local counter just so you can keep that being true, even
if there were no other need for it.  (Since I've not read the thread,
I'll refrain from asking how you're gonna clean up at transaction end
if there's no local memory of what locks you hold.)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: SSI-related code drift between index_getnext() and heap_hot_search_buffer()
Следующее
От: Leon Smith
Дата:
Сообщение: Exporting closePGconn from libpq