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 71BBB9FB1D2 for ; Fri, 4 Aug 2006 01:27:26 -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 83640-08 for ; Fri, 4 Aug 2006 04:27:17 +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 5C6F89FB267 for ; Fri, 4 Aug 2006 01:27:17 -0300 (ADT) Received: from [192.168.4.40] (account jconway [192.168.4.40] verified) by joeconway.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 4141624; Thu, 03 Aug 2006 21:27:16 -0700 Message-ID: <44D2CCA4.8040507@joeconway.com> Date: Thu, 03 Aug 2006 21:27:16 -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: Re: VALUES clause memory optimization 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> <2922.1154609337@sss.pgh.pa.us> In-Reply-To: <2922.1154609337@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-Archive-Number: 200608/188 X-Sequence-Number: 87681 Tom Lane wrote: > 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. What about for the specific case of an InsertStmt? It seems that we could at least get away with freeing the raw-expression list in that case. In terms of freeing an entire arbitrary node, could we create a backend/nodes/freefuncs.c file that does a recursive freeObject() similar to the way copyObject() does in backend/nodes/copyfuncs.c? > My advice is to get that low-hanging fruit > in transformInsertRow and leave the other ideas for 8.3. OK. This should be safe also, correct? Thanks, Joe 8<---------------------------------------- diff -c -r1.341 analyze.c *** src/backend/parser/analyze.c 2 Aug 2006 01:59:46 -0000 1.341 --- src/backend/parser/analyze.c 2 Aug 2006 05:13:20 -0000 *************** *** 2191,2196 **** --- 2196,2202 ---- for (i = 0; i < sublist_length; i++) { coltypes[i] = select_common_type(coltype_lists[i], "VALUES"); + list_free(coltype_lists[i]); } newExprsLists = NIL;