Re: Straightforward changes for increased SMP scalability

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Straightforward changes for increased SMP scalability
Date: 2007-07-16 15:36:18
Message-ID: 469B9072.9040702@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>
>> +1 on the idea (I can speak to the technical side). What I can say is that it
>> is pretty much known that after 8 cores we slow down. Although 8.2 is better
>> than any other release in this regard.
>
> Wait, what benchmarks have you seen where we slow down?

The production type. :)

Hmm maybe that is a bad way to put it. I am not saying we slow down like
we move slower than before. I mean per processor performance goes down.
If I have 4 Cores things rock and roll. If I have 8 cores (and obvious
sufficient workload) things rock and roll louder than 4 cores.

If I have 16 cores, things are still really loud but I start to not be
able to tell the difference. The percentage of improvement is much lower.

E.g, 16 cores works and PostgreSQL work great, but it is not nearly as
fantastic with 16 cores as 8 cores (in terms percentage gain).

Sincerely,

Joshua D. Drake

>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2007-07-16 15:41:49 Re: minor compiler warning on OpenBSD
Previous Message Gregory Stark 2007-07-16 15:22:01 Re: Straightforward changes for increased SMP scalability