Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id D26E89FB89D for ; Mon, 23 Jul 2007 14:50:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 18604-08 for ; Mon, 23 Jul 2007 14:50:18 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail01.enterprisedb.com (webmail.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id E734E9FB8F6 for ; Mon, 23 Jul 2007 14:50:18 -0300 (ADT) thread-index: AcfNUfammaC3F91DR6O+aHlRrNhtng== Received: from [192.168.0.5] ([81.6.216.155]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jul 2007 13:50:29 -0400 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Subject: Re: User concurrency thresholding: where do I look? From: "Simon Riggs" To: "Tom Lane" Cc: "Jignesh K. Shah" , "Josh Berkus" , , "Alvaro Herrera" In-Reply-To: <27521.1185208528@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> <27521.1185208528@sss.pgh.pa.us> Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 23 Jul 2007 18:50:53 +0100 Message-ID: <1185213053.4284.278.camel@ebony.site> MIME-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 17:50:29.0468 (UTC) FILETIME=[F54A49C0:01C7CD51] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/303 X-Sequence-Number: 25987 On Mon, 2007-07-23 at 12:35 -0400, Tom Lane wrote: > "Simon Riggs" 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. I do have the bitmap patch currently applied, but it doesn't touch that part of the code. (gdb) p size $1 = 8232 (gdb) p sizeof(int) $2 = 4 (gdb) p sizeof(BTScanPosData) $3 = 4104 Since my notes say I got 8228 last year, seems reasonable. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com