On Mon, Mar 29, 2010 at 12:42 PM, Chris Barnes
<compuguruchrisbarnes@hotmail.com> wrote:
>
> We have two camps that think that the speed of cpu processors is/aren't
> relative to the number of transactions that postgres that can performed per
> second.
>
> I am of the opinion that is we throw the faster processors at the database
> machine, there will be better performance.
which tastes better, a round fruit or a oval fruit? :-).
postgres can become i/o bound or cpu bound depending on the
application, or specific things you are doing. if your application is
highly latency sensitive, then more cpu power is always nice.
cpu and i/o have completely different cost/performance scaling metrics:
cpu is very cheap to scale up to a point (when you hit limits of x86
at current levels) then becomes extremely expensive. cpu bound
problems tend to degrade relatively well when your limit is hit.
i/o is expensive to scale but has relatively linear relationship
between cost and performance. i/o bottleneck can bring your server to
a crawl, and sometimes comes out of nowhere when you nudge the work
the db has to do just a hair exceeding your system's ability to cope.
merlin