I wrote: > I haven't looked to see if any of these have an excessive amount of > local variables.
I poked through the call stack and found that the only function in this nest that seems to have a large amount of local variables is ExecMakeFunctionResult(). The space hog there is the local FunctionCallInfoData struct, which requires ~500 bytes on a 32-bit machine and ~900 bytes on a 64-bit one. Now the interesting thing about that is that we *also* keep a FunctionCallInfoData struct in the FuncExprState. The reason for this redundancy is stated to be: /* * For non-set-returning functions, we just use a local-variable * FunctionCallInfoData. For set-returning functions we keep the callinfo * record in fcache->setArgs so that it can survive across multiple * value-per-call invocations. (The reason we don't just do the latter * all the time is that plpgsql expects to be able to use simple * expression trees re-entrantly. Which might not be a good idea, but the * penalty for not doing so is high.) */ AFAICS this argument is no longer valid given the changes we made last week to avoid collisions due to reuse of fcinfo->flinfo->fn_extra. I'm pretty strongly tempted to get rid of the local-variable FunctionCallInfoData and just use the one in the FuncExprState always. That would simplify and marginally speed up the function-call code, which seems surely worth doing regardless of any savings in stack depth. I'm not sure that this would save enough stack space to make the buildfarm critters happy, but it might. However, I wouldn't care to risk changing this in the back branches, so we'd still need some other plan for fixing the buildfarm failures. Any objections? regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers