On Wed, 27 Jan 2010 22:06:43 +0200
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Ivan Sergio Borgonovo wrote:
> > 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?
> > It's a pain to save the context just to save a pointer inside a
> > structure, it would be more convenient to just process all the
> > structure and return it as a Tuplestore in one pass.
>
> When the set-returning-function feature was written originally,
> years ago, the tuple at a time mode did really work tuple at a
> time. But it had issues and was axed out of the patch before it
> was committed, to keep it simple. The idea was to revisit it at
> some point, but it hasn't bothered anyone enough to fix it. It's
> basically "not implemented yet".
Summing it up:
1) tuple at a time theoretically should be better and "future proof" once someone write the missing code but the code
isstill not there
2) practically there is no substantial extra cost in returning tuple at a time
Is 2) really true?
It seems that materialized mode is much simpler. It requires a lot
less code and it doesn't force you to save local variables and then
restore them every time.
So does it still make sense to get an idea about when the returned
data set and complexity of computation really fit value_per_call or
materialized mode?
What could happen between function calls in value_per_call?
Would still value_per_call offer a chance to postgresql/OS to better
allocate CPU cycles/memory?
thanks
--
Ivan Sergio Borgonovo
http://www.webthatworks.it