thread-index: AcfNV4wXlFBYonMwTRi8WkHfx6Af2g==
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: User concurrency thresholding: where do I look?
From: "Simon Riggs" <simon@2ndquadrant.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Jignesh K. Shah" <J.K.Shah@Sun.COM>, "Josh Berkus" <josh@agliodbs.com>,
	<pgsql-performance@postgresql.org>,
	"Alvaro Herrera" <alvherre@commandprompt.com>
In-Reply-To: <1545.1185214760@sss.pgh.pa.us>
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> <15343.1184965054@sss.pgh.pa.us>
	<1185180668.4284.149.camel@ebony.site>
	<23848.1185199901@sss.pgh.pa.us>
	<1185201556.4284.243.camel@ebony.site>
	<25095.1185202498@sss.pgh.pa.us>
	<1185205663.4284.249.camel@ebony.site>
	<1185212261.4284.270.camel@ebony.site>
	<1545.1185214760@sss.pgh.pa.us>
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 23 Jul 2007 19:30:48 +0100
Message-ID: <1185215448.4284.295.camel@ebony.site>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2007-07-23 at 14:19 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > currPos and markPos are defined as BTScanPosData, which is an array of
> > BTScanPosItems. That makes BTScanOpaqueData up to 8232 bytes, which
> > seems wasteful since markPos is only ever used during merge joins. Most
> > of that space isn't even used during merge joins either, we just do that
> > to slightly optimise the speed of the restore during merge joins.
> 
> Ah.  I was seeing it as 6600 bytes on HPPA and 6608 on x86_64, but
> I forgot that both of those architectures have MAXALIGN = 8.  On a
> MAXALIGN = 4 machine, MaxIndexTuplesPerPage will be significantly
> larger, leading to larger BTScanPosData.
> 
> Not sure it's worth fooling with, given that these days almost everyone
> who's seriously concerned about performance is probably using 64bit
> hardware.  One less malloc cycle per indexscan is never going to be a
> measurable savings anyway...

Oh sure, I was thinking to avoid Solaris' mutex by avoiding malloc()
completely.

-- 
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com