čt 15. 10. 2020 v 20:17 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Pavel Stehule <pavel.steh...@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 https://commitfest.postgresql.org/30/1608/ Anyway, I think another related issue will be in work with optimized (cached) target. > regards, tom lane >
