Re: plan cache doesn't clean plans with references to dropped procedures

čt 15. 10. 2020 v 20:17 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > I am playing with fixing the speed of CALL statement in a non atomic
> > context, and when I tested my patch I found another issue of CALL
> statement
> > - an invalidation of plans doesn't work for CALL statement (in atomic
> > context).
>
> Yeah, that's not the plancache's fault. CALL doesn't register any
> dependencies for the parsed expression it keeps in its parsetree.
>
> I remain of the opinion that we need to decide whether CALL is
> a utility command or an optimizable statement, and then make it
> follow the relevant set of rules. It can't live halfway between,
> especially not when none of the required infrastructure has been
> built to allow it to act like an optimizable statement. (Hm,
> I could swear we discussed this before, but searching the archives
> doesn't immediately turn up the thread. Anyway, you don't get to
> do parse analysis in advance of execution when you are a utility
> command.)
>
> Probably the only feasible fix for the back branches is to go in the
> utility-command direction, which means ripping out the pre-parsed
> expression in CallStmt. Somebody could look at making it act like an
> optimizable statement in the future; but that'll involve touching a
> nontrivial amount of code, and I'm not sure how much performance it'll
> really buy.
>

Maybe I wrote necessary code (or some part) for LET statement

https://commitfest.postgresql.org/30/1608/

Anyway, I think another related issue will be in work with optimized
(cached) target.

> regards, tom lane
>