Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id BA8659FA2D3 for ; Mon, 23 Jul 2007 11:38:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 51246-02 for ; Mon, 23 Jul 2007 11:38:29 -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 B15C19FB3D8 for ; Mon, 23 Jul 2007 11:38:38 -0300 (ADT) thread-index: AcfNNy8G55cxmCaxRES/sWc2+Rw8Rw== 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 10:38:49 -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: <23848.1185199901@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> Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 23 Jul 2007 15:39:16 +0100 Message-ID: <1185201556.4284.243.camel@ebony.site> MIME-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 14:38:49.0625 (UTC) FILETIME=[2ED98090:01C7CD37] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/290 X-Sequence-Number: 25974 On Mon, 2007-07-23 at 10:11 -0400, Tom Lane wrote: > "Simon Riggs" writes: > > EState is about 8300 bytes, > > What? > > (gdb) p sizeof(EState) > $1 = 112 > > This is on a 32-bit machine, but even on 64-bit it wouldn't be more than > double that. > > > Would it be worth a special case in the palloc system to avoid having to > > repeatedly issue external memory allocation calls? > > The appropriate hack would be to change the AllocSetContextCreate > initial-size parameter for the containing context. But I really have > no idea what you're on about. 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. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com