Re: Proposal of tunable fix for scalability of 8.4

"Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> wrote:
> On 03/11/09 18:27, Kevin Grittner wrote:
>> "Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> wrote:

>>> Rerunning similar tests on a 64-thread UltraSPARC T2plus based
>>> server config
>>
>>> (IO is not a problem... all in RAM .. no disks):
>>> Time:Users:Type:TPM: Response Time
>>> 60: 100: Medium Throughput: 10552.000 Avg Medium Resp: 0.006
>>> 120: 200: Medium Throughput: 22897.000 Avg Medium Resp: 0.006
>>> 180: 300: Medium Throughput: 33099.000 Avg Medium Resp: 0.009
>>> 240: 400: Medium Throughput: 44692.000 Avg Medium Resp: 0.007
>>> 300: 500: Medium Throughput: 56455.000 Avg Medium Resp: 0.007
>>> 360: 600: Medium Throughput: 67220.000 Avg Medium Resp: 0.008
>>> 420: 700: Medium Throughput: 77592.000 Avg Medium Resp: 0.009

>> I'm a lot more interested in what's happening between 60 and 180
than
>> over 1000, personally. If there was a RAID involved, I'd put it
down
>> to better use of the numerous spindles, but when it's all in RAM it
>> makes no sense.

> The problem is the CPUs are not all busy there is plenty of idle
cycles
> since PostgreSQL ends up in situations where they are all waiting for

> lockacquires for exclusive..

Precisely. This is the area where it seems there is the most to gain.
The area you're looking at seems to have less than a 2X gain
available.
This part of the curve clearly has much more.

-Kevin