Pavel Stehule <pavel.stehule@gmail.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.
regards, tom lane