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: <46A1205B.8010205@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> <14909.1184962561@sss.pgh.pa.us>
	<46A1205B.8010205@sun.com>
Comments: In-reply-to "Jignesh K. Shah" <J.K.Shah@Sun.COM>
	message dated "Fri, 20 Jul 2007 16:51:39 -0400"
Date: Fri, 20 Jul 2007 16:57:34 -0400
Message-ID: <15343.1184965054@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
> What its saying is that there are holds/waits in trying to get locks 
> which are locked at Solaris user library levels called from the  
> postgresql functions:
> For example both the following functions are hitting on the same mutex 
> lock  0x10059e280  in Solaris Library call:
> postgres`AllocSetDelete+0x98
> postgres`AllocSetAlloc+0x1c4

That's a perfect example of the sort of useless overhead that I was
complaining of just now in pgsql-patches.  Having malloc/free use
an internal mutex is necessary in multi-threaded programs, but the
backend isn't multi-threaded.  And yet, apparently you can't turn
that off in Solaris.

(Fortunately, the palloc layer is probably insulating us from malloc's
performance enough that this isn't a huge deal.  But it's annoying.)

			regards, tom lane