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.
> There probably isn't much difference in CPU usage either.
On Wed, 27 Jan 2010 10:34:10 -0500
Andrew Dunstan <andrew@dunslane.net> wrote:
> If you don't know your memory use will be light, use materialized
> mode. For small results the data will still be in memory anyway.
> The Tuplestore will only spill to disk if it grows beyond a
> certain size.
I keep on missing something.
Considering all the context switching stuff, the "first call"
initialization etc... I'd expect that what's collecting the result
was going to push it downstream a bit at a time.
What's actually happening is... the result get collected anyway in a
Tuplestore.
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.
BTW thanks to Greg for pointing me once more to Joe Conway's
tutorial. When I read it the first time I wasn't in a condition to
take advantage of it. Now it looks more useful.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
