From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Scott Carey <scott@richrelevance.com>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Thu, 12 Mar 2009 13:49:37 -0400
Message-ID: <49B94B31.2010201@sun.com> (raw)
In-Reply-To: <49B8E044.EE98.0025.0@wicourts.gov>
References: <49B7F470.EE98.0025.0@wicourts.gov>
<C5DDBB25.3333%scott@richrelevance.com>
<49B8E044.EE98.0025.0@wicourts.gov>
On 03/12/09 11:13, Kevin Grittner wrote:
>>>> Scott Carey <scott@richrelevance.com> wrote:
>>>>
>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
>>
>>
>>> 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.
>>>
>> If there is enough lock contention and a common lock case is a short
>> lived shared lock, it makes perfect sense sense. Fewer readers are
>> blocked waiting on writers at any given time. Readers can 'cut' in
>> line ahead of writers within a certain scope (only up to the number
>> waiting at the time a shared lock is at the head of the queue).
>> Essentially this clumps up shared and exclusive locks into larger
>> streaks, and allows for higher shared lock throughput.
>>
>
> 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.
>
> -Kevin
>
>
Every user has a think time (200ms) to wait before doing the next
transaction which results in idle time and theoretically allows other
users to run in between ..
-Jignesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, Kevin.Grittner@wicourts.gov, scott@richrelevance.com
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <49B94B31.2010201@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox