Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 4E19D9FB81B
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 23 Jul 2007 13:36:01 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 62486-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 23 Jul 2007 13:35:57 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 28A929FB78A
	for <pgsql-performance@postgresql.org>;
	Mon, 23 Jul 2007 13:35:58 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l6NGZShK027522;
	Mon, 23 Jul 2007 12:35:28 -0400 (EDT)
To: "Simon Riggs" <simon@2ndquadrant.com>
cc: "Jignesh K. Shah" <J.K.Shah@Sun.COM>, "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: <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>
Comments: In-reply-to "Simon Riggs" <simon@2ndquadrant.com>
	message dated "Mon, 23 Jul 2007 16:47:43 +0100"
Date: Mon, 23 Jul 2007 12:35:28 -0400
Message-ID: <27521.1185208528@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200707/293
X-Sequence-Number: 25977

"Simon Riggs" <simon@2ndquadrant.com> writes:
> 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?

Are you working with stock sources?  The only allocation exceeding 1K
that I can see during pgbench is BTScanOpaqueData, which is 6600 bytes.
(Checked by setting a conditional breakpoint on AllocSetAlloc.)  The
path that allocates a single-chunk block is never taken at all.

			regards, tom lane