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
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? |