Re: When deleting the plpgsql function, release the CachedPlan of the function

"=?utf-8?B?56ug5pmo5pum?=" <zhangchenxi(at)halodbtech(dot)com> writes:
> I think you misunderstand Man's meaning. In Man's example, the func cache
> neither dropped (will cause memory leak) nor reused. So the question here:
> 1. Drop the cache when func dropped
> 2. Keep the cache and reused when func recreate
> I prefer the 2ed solution.

There is no provision for re-using a plancache entry by discovering
that the query you want to cache matches some existing entry.
So your option 2 is not going to happen, at least not without a
large amount of new code. Furthermore, even if we wrote that code,
would it help much? There's not a lot of reason to think that
a recreated version of the plpgsql function would contain exactly
the same queries as before. There might be more reason to hope
that small plans (like for individual expressions) could be shared
among multiple plpgsql functions, but I'm still skeptical that
it'd be worth doing.

I think that Man's proposal to drop the plpgsql function-cache entry
and the plancache entries that it links to is a reasonable idea,
although of course it will only help in scenarios that may not be
common. (I doubt that typical applications have a lot of run-time
churn in pg_proc.)

BTW, could people try harder to maintain the thread links when
replying? This conversation has already degenerated into several
not-cross-linked threads in the archives. It looks like the
problem is that some of you are using "X-mailer: QQMail 2.x",
which apparently doesn't feel a need to generate References:
or In-reply-to: headers. That's super unfriendly behavior for
mailing lists.

regards, tom lane