To: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
cc: Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgresql.org,
	Alvaro Herrera <alvherre@commandprompt.com>
Subject: Re: User concurrency thresholding: where do I look? 
In-reply-to: <46A11116.5030905@sun.com> 
References: <200707190828.59088.josh@agliodbs.com>
	<200707191819.13899.josh@agliodbs.com>
	<15685.1184895926@sss.pgh.pa.us>
	<200707192138.39679.josh@agliodbs.com>
	<46A0FA31.2080208@sun.com> <12002.1184955831@sss.pgh.pa.us>
	<46A1055F.9010304@sun.com> <12445.1184958793@sss.pgh.pa.us>
	<46A11116.5030905@sun.com>
Comments: In-reply-to "Jignesh K. Shah" <J.K.Shah@Sun.COM>
	message dated "Fri, 20 Jul 2007 15:46:30 -0400"
Date: Fri, 20 Jul 2007 16:16:01 -0400
Message-ID: <14909.1184962561@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
> Tom Lane wrote:
>> So follow that up --- try to determine which lock is being contended
>> for.  There's some very crude code in the sources that you can enable
>> with -DLWLOCK_STATS, but probably DTrace would be a better tool.

> Using plockstat -A -s 5 -p $pid

I don't know what that is, but it doesn't appear to have anything to do
with Postgres LWLocks or spinlocks, which are the locks I was thinking of.
Try asking Robert Lor about this --- IIRC he had some dtrace probes to
work with our locks.

			regards, tom lane