Re: Performance under contention

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

In response to

Responses

Browse pgsql-performance by date

  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