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