thread-index: AcfNUfNvqtUQKtNRTBmdWMNFkaxdZA==
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: <1185205663.4284.249.camel@ebony.site>
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>
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 23 Jul 2007 18:37:41 +0100
Message-ID: <1185212261.4284.270.camel@ebony.site>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2007-07-23 at 16:48 +0100, Simon Riggs wrote:
> On Mon, 2007-07-23 at 10:54 -0400, Tom Lane wrote:
> > "Simon Riggs" <simon@2ndquadrant.com> writes:
> > > I looked at this last May and my notes say "ExecutorState". I guess that
> > > was wrong, but my analysis showed there was a single malloc of 8228
> > > bytes happening once per query during my tests. 
> > 
> > Well, if you can track down where it's coming from, we could certainly
> > hack the containing context's parameters.  But EState's not it.
> 
> Well, I discover there is an allocation of 8232 (inflation...) made once
> per statement by a memory context called... ExecutorState. Still not
> sure exactly which allocation this is, but its definitely once per
> statement on pgbench, which should narrow it down. Plan, query etc?
> 
> I don't see a way to hack the allocation, since the max chunk size is
> 8K.

It is the allocation of BTScanOpaqueData called from btrescan() in
nbtree.c

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.

Seems like we should allocate the memory when we do the first mark.

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