Re: Performance under contention
От
Robert Haas
Тема
Re: Performance under contention
Дата
Msg-id
AANLkTimLySOatnsAOJtW-pdfEWGF7A-J3QDORSPTANU6@mail.gmail.com
Ответ на
Re: Performance under contention (Tom Lane)
Список
Дерево обсуждения
Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Greg Smith <greg@2ndquadrant.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Jignesh Shah <jkshah@gmail.com>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Dave Crooke <dcrooke@gmail.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Віталій Тимчишин <tivv00@gmail.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Jignesh Shah <jkshah@gmail.com>
2010/12/8 Tom Lane : > Robert Haas writes: >> 2010/12/8 Tom Lane : >>> 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. > >> That seems like it might be feasible. The backend that holds the lock >> ought to be able to find out whether there's a PROCLOCK by looking at >> the LOCALLOCK table, and the LOCALLOCK has a pointer to the PROCLOCK. > > Hm, that is a real good point. Those shared memory data structures > predate the invention of the local lock tables, and I don't think we > looked real hard at whether we should rethink the fundamental > representation in shared memory given the additional local state. > The issue though is whether any other processes ever need to look > at a proc's PROCLOCKs. I think at least deadlock detection does. Sure, but it doesn't use the hash table to do it. All the PROCLOCKs for any given LOCK are in a linked list; we just walk it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-performance по дате отправления