Re: Proposal of tunable fix for scalability of 8.4

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <david(at)lang(dot)hm>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Greg Smith" <gsmith(at)gregsmith(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "Scott Carey" <scott(at)richrelevance(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)sun(dot)com>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: 2009-03-16 15:48:32
Message-ID: 49BE2E80.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

<david(at)lang(dot)hm> wrote:
> On Fri, 13 Mar 2009, Kevin Grittner wrote:
>> If all data access is in RAM, why can't 80 processes
>> keep 64 threads (on 8 processors) busy? Does anybody else think
>> that's an interesting question, or am I off in left field here?
>
> I don't think that anyone is arguing that it's not intersting, but I
> also think that complete dismissal of the existing test case is also
> wrong.

Right, I just think this point in the test might give more targeted
results. When you've got many more times the number of processes than
processors, of course processes will be held up. It seems to me that
this is the point where the real issues are least likely to get lost
in the noise. It also might point out delays from the clients which
would help in interpreting the results farther down the list.

One more reason this point is an interesting one is that it is one
that gets *worse* with the suggested patch, if only by half a percent.

Without:

600: 80: Medium Throughput: 82632.000 Avg Medium Resp: 0.005

with:

600: 80: Medium Throughput: 82241.000 Avg Medium Resp: 0.005

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Steben 2009-03-16 16:11:23 Performance of archive logging in a PITR restore
Previous Message Gregory Stark 2009-03-16 15:28:10 Re: Postgres benchmarking with pgbench