On 01/27/2010 09:49 AM, Ivan Sergio Borgonovo wrote: > On Wed, 27 Jan 2010 17:37:23 +0200 > Heikki Linnakangas <heikki.linnakan...@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
signature.asc
Description: OpenPGP digital signature