From: Grzegorz Jaśkiewicz <gryzman@gmail.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Jignesh K. Shah <J.K.Shah@sun.com>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Thu, 12 Mar 2009 15:31:28 +0000
Message-ID: <2f4958ff0903120831q4ca3d0a8o8f2571f16b316ecf@mail.gmail.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 Thu, Mar 12, 2009 at 3:13 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> 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.
I think you try to argue about oranges, and he does about pears. Your
argument has nothing to do with what you are saying, which you should
understand.
Scalability is something that is affected by everything, and fixing
this makes sens as much as looking at possible fixes to make raids
more scalable, which is looked at by someone else I think.
So please, don't say that this doesn't make sense because he tested it
against ram disc. That was precisely the point of exercise.
--
GJ
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: gryzman@gmail.com, Kevin.Grittner@wicourts.gov, scott@richrelevance.com, J.K.Shah@sun.com
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <2f4958ff0903120831q4ca3d0a8o8f2571f16b316ecf@mail.gmail.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