Re: Performance of aggregates over set-returning functions

OK, added to TODO:

* Reduce memory usage of aggregates in set returning functions

  http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php


---------------------------------------------------------------------------

Tom Lane wrote:
> 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.
> 
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance

-- 
  Bruce Momjian          http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +