On 01/27/2010 09:49 AM, Ivan Sergio Borgonovo wrote:
> On Wed, 27 Jan 2010 17:37:23 +0200
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
>
>> Currently, there's no difference in terms of memory needs. The
>> backend always materializes the result of a SRF into a tuplestore
>> anyway, if the function didn't do it itself. There has been
>> discussion of optimizing away that materialization step, but
>> no-one has come up with an acceptable patch for that yet.
> I keep on missing something.
> But then... why do we have all that logic to save the function
> context if anyway it is more convenient to process everything in one
> run?
As already pointed out, there is currently no difference between
value_per_call and materialize modes. The original intent was to have
both modes eventually, with the initial one being materialize
(historical note: my first SRF patch was value_per_call, but had
difficult issues to be solved, and the consensus was that materialize
was a simpler and safer approach for the first try at this feature).
The advantage of value_per_call (if it were not materialized anyway in
the backend) would be to allow pipelining, which enables very large
datasets to be streamed without exhausting memory or having to wait for
it all to be materialized.
Implementing true value_per_call is still something on my TODO list, but
obviously has not risen to a very high priority for me as it has now
been an embarrassing long time since it was put there. But that said,
materialize mode has proven extremely good at covering the most common
use cases with acceptable performance.
Joe