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 <bruce@momjian.us> 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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

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