Re: CPUs for new databases

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Ivan Voras <ivoras(at)freebsd(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: CPUs for new databases
Date: 2010-10-27 19:58:46
Message-ID: 4CC88476.7010804@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2010-10-27 20:10:15 Re: AIX slow buffer reads
Previous Message Tom Lane 2010-10-27 19:56:19 Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?