Re: Proposal of tunable fix for scalability of 8.4

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "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:09:41
Message-ID: C5DE9DF5.3388%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 3/12/09 10:53 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> You misunderstood me. I wasn't addressing the affects of his change,
> but rather the fact that his test shows a linear improvement in TPS up
> to 1000 connections for a 64 thread machine which is dealing entirely
> with RAM -- no disk access. Where's the bottleneck that allows this
> to happen? Without understanding that, his results are meaningless.

Yeah, that is a really good point. For a CPU-bound test you would
ideally expect linear performance improvement up to the point at which
number of active threads equals number of CPUs, and flat throughput
with more threads. The fact that his results don't look like that
should excite deep suspicion that something is wrong somewhere.

This does not in itself prove that the idea is wrong, but it does say
that there is some major effect happening in this test that we don't
understand. Without understanding it, it's impossible to guess whether
the proposal is helpful in any other scenario.

regards, tom lane

Only on the assumption that each thread in the load test is running in ASAP mode rather than a metered pace.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-03-12 18:28:01 Re: Proposal of tunable fix for scalability of 8.4
Previous Message Scott Carey 2009-03-12 18:08:44 Re: Proposal of tunable fix for scalability of 8.4