Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id DB2252E2EF4 for ; Thu, 6 Mar 2008 13:53:51 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 80817-01 for ; Thu, 6 Mar 2008 13:53:30 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4110B2E2FB2 for ; Thu, 6 Mar 2008 13:53:31 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m26HrS2h018717; Thu, 6 Mar 2008 12:53:28 -0500 (EST) To: Bruce Momjian cc: John Smith , pgsql-performance@postgresql.org Subject: Re: Performance of aggregates over set-returning functions In-reply-to: <200803061723.m26HNLN24410@momjian.us> References: <200803061723.m26HNLN24410@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Thu, 06 Mar 2008 12:23:21 -0500" Date: Thu, 06 Mar 2008 12:53:28 -0500 Message-ID: <18716.1204826008@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/134 X-Sequence-Number: 29088 Bruce Momjian writes: > This this a bug or TODO item? TODO, I think. I wouldn't want to risk pushing a change in this into back branches. regards, tom lane >> I'm not sure why it's like this. Some digging in the CVS history shows >> that indeed the code used to be in the other order, and I switched it >> (and added the second comment block) in this old commit: >> >> http://archives.postgresql.org/pgsql-committers/2000-08/msg00218.php >> >> I suppose that the SQL-function support at the time required that its >> calling memory context be persistent until it returned ExprEndResult, >> but I sure don't recall any details. It's entirely possible that that >> requirement no longer exists, or could easily be eliminated given all >> the other changes that have happened since then. nodeFunctionscan.c >> seems to reset the current context for each call of a SRF, so I'd think >> that anything that can't cope with that should have been flushed out >> by now. >> >> If you feel like poking at this, I *strongly* recommend doing your >> testing in an --enable-cassert build. You'll have no idea whether you >> freed stuff too early if you don't have CLOBBER_FREED_MEMORY enabled.