X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id E88059FB28E for ; Wed, 2 Aug 2006 21:19:02 -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 09839-06 for ; Thu, 3 Aug 2006 00:18:42 +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 827869FB22B for ; Wed, 2 Aug 2006 21:18:42 -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 4139755; Wed, 02 Aug 2006 17:18:39 -0700 Message-ID: <44D140DF.5080209@joeconway.com> Date: Wed, 02 Aug 2006 17:18:39 -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: "Hackers (PostgreSQL)" Subject: VALUES clause memory optimization (was: Values list-of-targetlists patch...) 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/96 X-Sequence-Number: 87589 Tom Lane wrote: > 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 transformExpr the comment implies that it should be safe to reapply to an already transformed expression. What if we free the raw_parser expression list/cells/nodes and replace it with the as-transformed one? Joe