Message-ID: <4C369346.6010501@postnewspapers.com.au>
Date: Fri, 09 Jul 2010 11:11:02 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
	rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Harpreet singh Wadhwa <harpreetsingh.wadhwa@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Need help in performance tuning.
References: <AANLkTiknhZhKtGDidBsMWtPJpRgln9DrrsCebCEYk5XE@mail.gmail.com>
In-Reply-To: <AANLkTiknhZhKtGDidBsMWtPJpRgln9DrrsCebCEYk5XE@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 9/07/2010 3:20 AM, Harpreet singh Wadhwa wrote:
> Hi,
>
>
> I want to fine tune my postgresql to increase number of connects it
> can handle in a minutes time.
> Decrease the response time per request etc.
> The exact case will be to handle around 100 concurrent requests.

If you're not using a connection pool, start using one.

Do you really need 100 *active* working query threads at one time? 
Because if you do, you're going to need a scary-big disk subsystem and a 
lot of processors.

Most people actually only need a few queries executing simultaneously, 
they just need lots of connections to the database open concurrently 
and/or lots of queries queued up for processing. For that purpose, a 
connection pool is ideal.

You will get BETTER performance from postgresql with FEWER connections 
to the "real" database that're all doing active work. If you need lots 
and lots of connections you should use a connection pool to save the 
main database the overhead of managing that.

--
Craig Ringer