Re: Performance under contention

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance under contention
Дата
Msg-id 14229.1291818863@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Performance under contention  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Performance under contention  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
Robert Haas <robertmhaas@gmail.com> writes:
>> Yeah, that was my concern, too, though Tom seems skeptical (perhaps
>> rightly). �And I'm not really sure why the PROCLOCKs need to be in a
>> hash table anyway - if we know the PROC and LOCK we can surely look up
>> the PROCLOCK pretty expensively by following the PROC SHM_QUEUE.

> Err, pretty INexpensively.

There are plenty of scenarios in which a proc might hold hundreds or
even thousands of locks.  pg_dump, for example.  You do not want to be
doing seq search there.

Now, it's possible that you could avoid *ever* needing to search for a
specific PROCLOCK, in which case eliminating the hash calculation
overhead might be worth it.  Of course, you'd still have to replicate
all the space-management functionality of a shared hash table.

            regards, tom lane

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

Предыдущее
От: Vlad Arkhipov
Дата:
Сообщение: Re: Slow BLOBs restoring
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Slow BLOBs restoring