Robert Haas <robertmhaas@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
