čt 15. 10. 2020 v 20:17 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
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.
Maybe I wrote necessary code (or some part) for LET statement
