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. > There probably isn't much difference in CPU usage either. On Wed, 27 Jan 2010 10:34:10 -0500 Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
