| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Scott Carey <scott(at)richrelevance(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "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-12 18:28:01 |
| Message-ID: | 12916.1236882481@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Scott Carey <scott(at)richrelevance(dot)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 switch rate trend. More information would be useful but the test is validated by the evidence that it is held up by lock contention.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron | 2009-03-12 18:32:38 | Re: Proposal of tunable fix for scalability of 8.4 |
| Previous Message | Scott Carey | 2009-03-12 18:09:41 | Re: Proposal of tunable fix for scalability of 8.4 |