From: Scott Carey <scott@richrelevance.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
To: Jignesh K. Shah <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Wed, 11 Mar 2009 19:01:57 -0700
Message-ID: <C5DDBB25.3333%scott@richrelevance.com> (raw)
In-Reply-To: <49B7F470.EE98.0025.0@wicourts.gov>
On 3/11/09 3:27 PM, "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.
Exclusive locks may be delayed, but will NOT be starved, since on the next iteration, a streak of exclusive locks will occur first in the list and they will all process before any more shared locks can go.
This will even help in on a single CPU system if it is read dominated, lowering read latency and slightly increasing write latency.
If you want to make this more fair, instead of freeing all shared locks, limit the count to some number, such as the number of CPU cores. Perhaps rather than wake-up-all-waiters=true, the parameter can be an integer representing how many shared locks can be freed at once if an exclusive lock is encountered.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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: scott@richrelevance.com, Kevin.Grittner@wicourts.gov, J.K.Shah@Sun.COM
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <C5DDBB25.3333%scott@richrelevance.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