From: James Cloos <cloos@jhcloos.com>
To: pgsql-performance@postgresql.org
Subject: Re: CPUs for new databases
Date: Tue, 26 Oct 2010 19:45:12 -0400
Message-ID: <m3ocagplgf.fsf@jhcloos.com> (raw)
In-Reply-To: <4CC73FEF.9020805@agliodbs.com>
References: <4CC6CFAA.10107@one.com>
<AANLkTi=ScGQiHB2ch+C_+K14TgjaO_3+x0+28QOFYeUU@mail.gmail.com>
<4CC73FEF.9020805@agliodbs.com>
>>>>> "JB" == Josh Berkus <josh@agliodbs.com> writes:
JB> In a general workload, fewer faster cores are better. We do not scale
JB> perfectly across cores. The only case where that's not true is
JB> maintaining lots of idle connections, and that's really better dealt
JB> with in software.
I've found that ram speed is the most limiting factor I've run into for
those cases where the db fits in RAM. The less efficient lookups run
just as fast when the CPU is in powersving mode as in performance, which
implies that the cores are mostly waiting on RAM (cache or main).
I suspect cache size and ram speed will be the most important factors
until the point where disk i/o speed and capacity take over.
I'm sure some db applications run computaionally expensive queries on
the server, but most queries seem light on computaion and heavy on
gathering and comparing.
It can help to use recent versions of gcc with -march=native. And
recent versions of glibc offer improved string ops on recent hardware.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cloos@jhcloos.com
Subject: Re: CPUs for new databases
In-Reply-To: <m3ocagplgf.fsf@jhcloos.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox