Re: Proposal of tunable fix for scalability of 8.4 - Mailing list pgsql-performance

From Tom Lane
Subject Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id 12916.1236882481@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal of tunable fix for scalability of 8.4  (Scott Carey <scott@richrelevance.com>)
Responses Re: Proposal of tunable fix for scalability of 8.4  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Proposal of tunable fix for scalability of 8.4  (Scott Carey <scott@richrelevance.com>)
List pgsql-performance
Scott Carey <scott@richrelevance.com> writes:
> They are not meaningless.  It is certainly more to understand, but the test is entirely valid without that.  In a CPU
bound/ RAM bound case, as concurrency increases you look for the throughput trend, the %CPU use trend and the context
switchrate trend.  More information would be useful but the test is validated by the evidence that it is held up by
lockcontention. 

Er ... *what* evidence?  There might be evidence somewhere that proves
that, but Jignesh hasn't shown it.  The available data suggests that the
first-order performance limiter in this test is something else.
Otherwise it should be possible to max out the performance with a lot
less than 1000 active backends.

            regards, tom lane

pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4
Next
From: Ron
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4