To: pgsql-performance@postgresql.org
From: Ivan Voras <ivoras@freebsd.org>
Subject: Re: Performance under contention
Date: Mon, 22 Nov 2010 16:38:28 +0100
Lines: 25
Message-ID: <ice2pd$ae8$1@dough.gmane.org>
References: <4CE9773D0200002500037CA6@gw.wicourts.gov>
	<iccjub$bn0$1@dough.gmane.org>
	<4CEA373D0200002500037CED@gw.wicourts.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6
In-Reply-To: <4CEA373D0200002500037CED@gw.wicourts.gov>

On 11/22/10 16:26, Kevin Grittner wrote:
> Ivan Voras<ivoras@freebsd.org>  wrote:
>> On 11/22/10 02:47, Kevin Grittner wrote:
>>> Ivan Voras  wrote:
>>>
>>>> After 16 clients (which is still good since there are only 12
>>>> "real" cores in the system), the performance drops sharply
>>>
>>> Yet another data point to confirm the importance of connection
>>> pooling.  :-)
>>
>> I agree, connection pooling will get rid of the symptom. But not
>> the underlying problem. I'm not saying that having 1000s of
>> connections to the database is a particularly good design, only
>> that there shouldn't be a sharp decline in performance when it
>> does happen. Ideally, the performance should remain the same as it
>> was at its peek.
>
> Well, I suggested that we add an admission control[1] mechanism,

It looks like a hack (and one which is already implemented by connection 
pool software); the underlying problem should be addressed.

But on the other hand if it's affecting so many people, maybe a warning 
comment in postgresql.conf around max_connections would be helpful.