Message-ID: <4CC88476.7010804@2ndquadrant.com>
Date: Wed, 27 Oct 2010 15:58:46 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Ivan Voras <ivoras@freebsd.org>
CC: pgsql-performance@postgresql.org
Subject: Re: CPUs for new databases
References: <4CC6CFAA.10107@one.com>
	<AANLkTi=ScGQiHB2ch+C_+K14TgjaO_3+x0+28QOFYeUU@mail.gmail.com>
	<4CC73FEF.9020805@agliodbs.com>
	<m3ocagplgf.fsf@jhcloos.com> <ia7r55$5ih$1@dough.gmane.org>
In-Reply-To: <ia7r55$5ih$1@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ivan Voras wrote:
> FWIW, yes - once the IO is fast enough or not necessary (e.g. the 
> read-mostly database fits in RAM), RAM bandwidth *is* the next 
> bottleneck and it really, really can be observed in actual loads.

This is exactly what I've concluded, after many rounds of correlating 
memory speed tests with pgbench tests against in-RAM databases.  And 
it's the reason why I've written the stream-scaling utility and been 
collecting test results from as many systems as possible.  That seemed 
to get dismissed upthread as not being the answer the poster was looking 
for, but I think you have to get a handle on that part before the rest 
of the trivia involved even matters.

I have a bunch more results that have been flowing in that I need to 
publish there soon.  Note that there is a bug in stream-scaling where 
sufficiently large systems can hit a compiler problem where it reports 
"relocation truncated to fit: R_X86_64_PC32 against `.bss'".  I have two 
of those reports and am working on resolving.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books