Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 1F9B863347F
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 11 Mar 2009 23:02:07 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 62131-03
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 11 Mar 2009 23:01:53 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from EXHUB018-3.exch018.msoutlookonline.net
	(exhub018-3.exch018.msoutlookonline.net [64.78.17.18])
	by mail.postgresql.org (Postfix) with ESMTP id 89DB16332EC
	for <pgsql-performance@postgresql.org>;
	Wed, 11 Mar 2009 23:02:02 -0300 (ADT)
Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by
	EXHUB018-3.exch018.msoutlookonline.net ([64.78.17.18]) with mapi;
	Wed, 11 Mar 2009 19:02:00 -0700
From: Scott Carey <scott@richrelevance.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
	"Jignesh K. Shah" <J.K.Shah@Sun.COM>
Date: Wed, 11 Mar 2009 19:01:57 -0700
Subject: Re: Proposal of tunable fix for scalability of 8.4
Thread-Topic: [PERFORM] Proposal of tunable fix for scalability of 8.4
Thread-Index: AcmimJnmGbPRV/+JS6yWzSVFHWlCPgAHevzo
Message-ID: <C5DDBB25.3333%scott@richrelevance.com>
In-Reply-To: <49B7F470.EE98.0025.0@wicourts.gov>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_C5DDBB253333scottrichrelevancecom_"
MIME-Version: 1.0
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=AWL=-0.000,
	HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200903/112
X-Sequence-Number: 33034

--_000_C5DDBB253333scottrichrelevancecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 waiti=
ng on writers at any given time.  Readers can 'cut' in line ahead of writer=
s within a certain scope (only up to the number waiting at the time a share=
d 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 thr=
oughput.
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 the=
y 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, lowe=
ring read latency and slightly increasing write latency.

If you want to make this more fair, instead of freeing all shared locks, li=
mit the count to some number, such as the number of CPU cores.  Perhaps rat=
her than wake-up-all-waiters=3Dtrue, the parameter can be an integer repres=
enting how many shared locks can be freed at once if an exclusive lock is e=
ncountered.


-Kevin

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


--_000_C5DDBB253333scottrichrelevancecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [PERFORM] Proposal of tunable fix for scalability of 8.4</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>On 3/11/09 3:27 PM, &quot;Kevin Grittner&quot; &lt;<a href=3D"Kevin.G=
rittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
I'm a lot more interested in what's happening between 60 and 180 than<BR>
over 1000, personally. &nbsp;If there was a RAID involved, I'd put it down<=
BR>
to better use of the numerous spindles, but when it's all in RAM it<BR>
makes no sense.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>If there is enough lock contention and a c=
ommon lock case is a short lived shared lock, it makes perfect sense sense.=
 &nbsp;Fewer readers are blocked waiting on writers at any given time. &nbs=
p;Readers can &#8216;cut&#8217; in line ahead of writers within a certain s=
cope (only up to the number waiting at the time a shared lock is at the hea=
d of the queue). &nbsp;Essentially this clumps up shared and exclusive lock=
s into larger streaks, and allows for higher shared lock throughput. &nbsp;=
<BR>
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 the=
y will all process before any more shared locks can go.<BR>
<BR>
This will even help in on a single CPU system if it is read dominated, lowe=
ring read latency and slightly increasing write latency.<BR>
<BR>
If you want to make this more fair, instead of freeing all shared locks, li=
mit the count to some number, such as the number of CPU cores. &nbsp;Perhap=
s rather than wake-up-all-waiters=3Dtrue, the parameter can be an integer r=
epresenting how many shared locks can be freed at once if an exclusive lock=
 is encountered. <BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>-Kevin<BR>
<BR>
--<BR>
Sent via pgsql-performance mailing list (<a href=3D"pgsql-performance@postg=
resql.org">pgsql-performance@postgresql.org</a>)<BR>
To make changes to your subscription:<BR>
<a href=3D"http://www.postgresql.org/mailpref/pgsql-performance">http://www=
.postgresql.org/mailpref/pgsql-performance</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C5DDBB253333scottrichrelevancecom_--