Re: Performance of aggregates over set-returning functions

От: Tom Lane
Тема: Re: Performance of aggregates over set-returning functions
Дата: ,
Msg-id: 18716.1204826008@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Performance of aggregates over set-returning functions  (Bruce Momjian)
Ответы: Re: Performance of aggregates over set-returning functions  (Bruce Momjian)
Список: pgsql-performance

Скрыть дерево обсуждения

Performance of aggregates over set-returning functions  ("John Smith", )
 Re: Performance of aggregates over set-returning functions  (Tom Lane, )
  Re: Performance of aggregates over set-returning functions  ("John Smith", )
   Re: Performance of aggregates over set-returning functions  (Tom Lane, )
    Re: Performance of aggregates over set-returning functions  (Bruce Momjian, )
     Re: Performance of aggregates over set-returning functions  (Tom Lane, )
      Re: Performance of aggregates over set-returning functions  (Bruce Momjian, )
    Re: Performance of aggregates over set-returning functions  ("John Smith", )
     Re: Performance of aggregates over set-returning functions  (Tom Lane, )

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.


В списке pgsql-performance по дате сообщения:

От: "Stephen Denne"
Дата:
Сообщение: Re: Why the difference in plans ?
От: Dave Cramer
Дата:
Сообщение: Re: Why the difference in plans ?