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
|
Список | 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 по дате отправления: