Re: Processor speed relative to postgres transactions per second

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

In response to

Browse pgsql-general by date

  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"