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