> Patch attached with this mail. > The previous patch was WIP. Please take a look at this one instead. I hope this handles the cases where results are not just base datums but palloc'ed datums like string types too.
Regards, Nikhils > The SRF has its own long-lived "SRF multi-call context" anyways. And > AIUI, SRFs return tuples one-by-one or do we materialize the same into > a tuplestore in some cases? > > Regards, > Nikhils > > On Wed, May 5, 2010 at 7:23 PM, Nikhil Sontakke > <nikhil.sonta...@enterprisedb.com> wrote: >> Hi, >> >> I saw this behavior with latest GIT head: >> >> create table xlarge(val numeric(19,0)); >> insert into xlarge values(generate_series(1,5)); >> >> The above generate series will return an int8 which will then be >> casted to numeric (via int8_to_numericvar) before being inserted into >> the table. I observed that the ExprContext memory associated with >> econtext->ecxt_per_tuple_memory is slowly bloating up till the end of >> the insert operation. >> >> This becomes significant the moment we try to insert a significant >> number of entries using this SRF. I can see the memory being consumed >> by the PG backend slowly grow to a large percentage. >> >> I see that the executor (take ExecResult as an example) does not reset >> the expression context early if an SRF is churning out tuples. What >> could be a good way to fix this? >> >> Regards, >> Nikhils >> -- >> http://www.enterprisedb.com >> > > > > -- > http://www.enterprisedb.com > -- http://www.enterprisedb.com
diff --git a/src/backend/executor/nodeResult.c b/src/backend/executor/nodeResult.c index 94796d5..ed437a0 100644 --- a/src/backend/executor/nodeResult.c +++ b/src/backend/executor/nodeResult.c @@ -91,6 +91,9 @@ ExecResult(ResultState *node) } } + /* release memory associated with the previous tuple */ + ResetExprContext(econtext); + /* * Check to see if we're still projecting out tuples from a previous scan * tuple (because there is a function-returning-set in the projection @@ -106,13 +109,6 @@ ExecResult(ResultState *node) } /* - * Reset per-tuple memory context to free any expression evaluation - * storage allocated in the previous tuple cycle. Note this can't happen - * until we're done projecting out tuples from a scan tuple. - */ - ResetExprContext(econtext); - - /* * if rs_done is true then it means that we were asked to return a * constant tuple and we already did the last time ExecResult() was * called, OR that we failed the constant qual check. Either way, now we
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
