From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Chris Barnes <compuguruchrisbarnes(at)hotmail(dot)com> |
Cc: | Postgres General Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Processor speed relative to postgres transactions per second |
Date: | 2010-03-30 14:22:07 |
Message-ID: | b42b73151003300722p6cc13d89lf10a80c462a2a366@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Mar 29, 2010 at 12:42 PM, Chris Barnes
<compuguruchrisbarnes(at)hotmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-30 14:34:28 | Re: different behaviour between select and delete when constraint_exclusion = partition |
Previous Message | moataz Elmasry | 2010-03-30 13:58:49 | createuser: could not connect to database postgres: FATAL: password authentication failed for user "postgres" |