X-Original-To: pgsql-patches-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 648759FA4A8 for ; Wed, 2 Aug 2006 15:10:30 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 01438-02 for ; Wed, 2 Aug 2006 18:10:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from joeconway.com (joeconway.com [68.15.9.201]) by postgresql.org (Postfix) with ESMTP id 680D89FA6B5 for ; Wed, 2 Aug 2006 15:10:13 -0300 (ADT) Received: from [206.190.70.130] (account jconway HELO [172.16.1.115]) by joeconway.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 4139302; Wed, 02 Aug 2006 11:10:11 -0700 Message-ID: <44D0EA83.7050702@joeconway.com> Date: Wed, 02 Aug 2006 11:10:11 -0700 From: Joe Conway User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane CC: pgsql-patches@postgreSQL.org Subject: Re: Values list-of-targetlists patch for comments (was Re: References: <44B69778.5050104@dunslane.net> <50461.84.63.113.55.1152832991.squirrel@pezone.net> <44B7ADFC.90205@dunslane.net> <44D03D9F.80203@joeconway.com> <15263.1154526181@sss.pgh.pa.us> <44D0AF87.2030304@joeconway.com> <16892.1154528708@sss.pgh.pa.us> <44D0B9C1.2020608@joeconway.com> <17704.1154534183@sss.pgh.pa.us> In-Reply-To: <17704.1154534183@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.816 tagged_above=0 required=5 tests=SPF_HELO_SOFTFAIL, SPF_SOFTFAIL X-Spam-Level: *** X-Archive-Number: 200608/58 X-Sequence-Number: 20574 Tom Lane wrote: > Yeah, I've just been doing that and some hand analysis too. What I get > (on a 64-bit machine) is that essentially all the space goes into > > lists of A_Const lists: 320000000 > lists of Const lists: 320000000 > transformInsertRow extra lists: 144000000 > > I think we could safely list_free the input list in transformInsertRow > as your patch suggests, which would buy back the 144M part. But I don't > believe it's safe at all to free the raw_parser output --- the grammar > sometimes makes multiple links to the same subtree, eg in BETWEEN. > In any case the patch as proposed wouldn't catch all the detritus for > any case more complicated than a simple integer constant. :-( > The way that the list memory usage works (again, 64-bit machine) is > > sizeof(List) = 24 > sizeof(ListCell) = 16 > sizeof(A_Const) = 32 > > Each of these nodes will have 16 bytes palloc overhead, and the List > header will be rounded up to 32 bytes as well, so we have total space > for a 3-element integer list of > 32+16 + (16+16 + 32+16) * 3 > Add in 16+16 for the associated ListCell of the top list-of-lists, > and you come to 320 bytes per sublist. Const happens to also be > 32 bytes so the transformed lists are the same size. What if we built an array of A_Const nodes instead of a List? Maybe we could use something akin to appendStringInfo()/enlargeStringInfo() to build the array of nodes and enlarge it in chunks. Joe