Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 134AE9FB214 for ; Mon, 23 Jul 2007 12:47:27 -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 11333-04-3 for ; Mon, 23 Jul 2007 12:47:24 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 0B29A9FA43D for ; Mon, 23 Jul 2007 12:47:23 -0300 (ADT) thread-index: AcfNQMtFYPD86dnuTt+JKr0J3VKD3A== Received: from [172.24.32.33] ([62.232.55.118]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jul 2007 11:47:37 -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: <25095.1185202498@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> Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 23 Jul 2007 16:47:43 +0100 Message-ID: <1185205663.4284.249.camel@ebony.site> MIME-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 15:47:37.0281 (UTC) FILETIME=[CB1FD310:01C7CD40] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/292 X-Sequence-Number: 25976 On Mon, 2007-07-23 at 10:54 -0400, Tom Lane wrote: > "Simon Riggs" 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. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com