Merlin Moncure <mmonc...@gmail.com> writes:
> BTW, while the fix does address the cleanup performance issue, it's
> still the case that anonymous code blocks burn up lots of resident
> memory (my 315k example I tested with ate around 8gb IIRC) when run
> like this. My question is, if the pl/pgsql code block is anonymous
> and not in some kind of a loop, why bother caching the plan at all?
Nobody got around to it. Also, as you note, it's not as simple as
"don't cache if in a DO block". You'd need to track whether you were
inside any sort of looping construct. Depending on how difficult
that turned out to be, it might add overhead to regular functions
that we don't want.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
