On Mon, Mar 29, 2010 at 12:42 PM, Chris Barnes <compuguruchrisbarnes@xxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
