Re: Performance under contention
От | Tom Lane |
---|---|
Тема | Re: Performance under contention |
Дата | |
Msg-id | 14229.1291818863@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance under contention (Robert Haas) |
Ответы |
Re: Performance under contention
(Robert Haas)
|
Список | pgsql-performance |
Дерево обсуждения
Performance under contention
(Ivan Voras,
)
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Jignesh Shah, )
Re: Performance under contention (Omar Kilani, )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Craig Ringer, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Vitalii Tymchyshyn, )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Greg Smith, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Jignesh Shah, )
Re: Performance under contention (Jignesh Shah, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Tom Lane, )
Re: Performance under contention (Dave Crooke, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Віталій Тимчишин, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Tom Lane, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Tom Lane, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Jignesh Shah, )
Re: Performance under contention (Omar Kilani, )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Craig Ringer, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Vitalii Tymchyshyn, )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention ("Kevin Grittner", )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Greg Smith, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Jignesh Shah, )
Re: Performance under contention (Jignesh Shah, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Tom Lane, )
Re: Performance under contention (Dave Crooke, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Віталій Тимчишин, )
Re: Performance under contention (Ivan Voras, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Tom Lane, )
Re: Performance under contention (Robert Haas, )
Re: Performance under contention (Tom Lane, )
Re: Performance under contention (Robert Haas, )
Robert Haas <> 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 по дате отправления:
Предыдущее
От: Bryce NesbittДата:
Сообщение: Re: hashed subplan 5000x slower than two sequential operations