Message-ID: <4DF21862.3030008@postnewspapers.com.au>
Date: Fri, 10 Jun 2011 21:13:06 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10
MIME-Version: 1.0
To: Anibal David Acosta <aa@devshock.com>
CC: tv@fuzzy.cz, pgsql-performance@postgresql.org
Subject: Re: how much postgres can scale up?
References: <000601cc2761$a2e3a280$e8aae780$@devshock.com>
	<243bcc276983a6b1e2bbc783c3a5b7db.squirrel@sq.gransy.com>
	<000f01cc276d$df82edc0$9e88c940$@devshock.com>
In-Reply-To: <000f01cc276d$df82edc0$9e88c940$@devshock.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 06/10/2011 08:56 PM, Anibal David Acosta wrote:
> The version is Postgres 9.0
> Yes, I setup the postgres.conf according to instructions in the
> http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
>
>
> Cool, I will check this
> http://wiki.postgresql.org/wiki/Logging_Difficult_Queries
>
> Looks like great starting point to find bottleneck
>
> But so, Is possible in excellent conditions that two connections duplicate the quantity of transactions per second?

For two connections, if you have most of the data cached in RAM or you 
have lots of fast disks, then sure. For that matter, if they're 
synchronized scans of the same table then the second transaction might 
perform even faster than the first one!

There are increasing overheads with transaction synchronization, etc 
with number of connections, and they'll usually land up contending for 
system resources like RAM (for disk cache, work_mem, etc), disk I/O, and 
CPU time. So you won't generally get linear scaling with number of 
connections.

Greg Smith has done some excellent and detailed work on this. I highly 
recommend reading his writing, and you should consider buying his recent 
book "PostgreSQL 9.0 High Performance".

See also:

http://wiki.postgresql.org/wiki/Performance_Optimization

There have been lots of postgresql scaling benchmarks done over time, 
too. You'll find a lot of information if you look around the wiki and 
Google.

--
Craig Ringer