From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Віталій Тимчишин <tivv00(at)gmail(dot)com>, Ivan Voras <ivoras(at)freebsd(dot)org>, Jignesh Shah <jkshah(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance under contention |
Date: | 2010-12-08 14:34:23 |
Message-ID: | 14229.1291818863@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-12-08 14:46:21 | Re: Slow BLOBs restoring |
Previous Message | Vlad Arkhipov | 2010-12-08 08:50:05 | Re: Slow BLOBs restoring |