X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id C995F9FB24D for ; Thu, 3 Aug 2006 09:49:19 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 02897-04 for ; Thu, 3 Aug 2006 09:49:00 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 83CBF9FA5DC for ; Thu, 3 Aug 2006 09:49:02 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k73CmvTZ002923; Thu, 3 Aug 2006 08:48:57 -0400 (EDT) To: Joe Conway cc: "Hackers (PostgreSQL)" Subject: Re: VALUES clause memory optimization (was: Values list-of-targetlists patch...) In-reply-to: <44D140DF.5080209@joeconway.com> 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> <44D140DF.5080209@joeconway.com> Comments: In-reply-to Joe Conway message dated "Wed, 02 Aug 2006 17:18:39 -0700" Date: Thu, 03 Aug 2006 08:48:57 -0400 Message-ID: <2922.1154609337@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.172 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/105 X-Sequence-Number: 87598 Joe Conway writes: > 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? How are you going to do the "replace" bit? The entire problem is that you don't know where are all the down-links leading to the subexpression you are currently working on. The reason we could safely list_free inside transformInsertRow is that we know all its callers have just built the passed-in list and so there are no other pointers to it. That doesn't apply in the general case of grammar output. I think in the long run we probably ought to fix things so that the grammar never outputs any multiply-linked trees; that little shortcut has been a continuing source of grief for many reasons. I can't see doing that for 8.2 though. My advice is to get that low-hanging fruit in transformInsertRow and leave the other ideas for 8.3. regards, tom lane