On Thu, 10 Nov 2022 at 04:11, <n.kobzarev@xxxxxxxxxxxxxxxx> wrote: > If someone would create delayed locking for generic plans, after parameters > are known and partition pruning occurs, I believe generic plan will be on > pars with custom. > So, I`m sticking with plan cache parameter for feature development, that was > clear. The current problem is that the locks must be obtained on the objects mentioned in the plan so that we can check if anying has been modified that might invalidate the prepared plan. For example, index has been dropped, partition dropped, etc. The partition pruning in your prepared plan is currently done during executor startup, which is after the locks are obtained (which is why we must lock everything in the plan). There is a patch around at the moment that moves the run-time partition pruning away from executor startup to before we obtain the locks so that we can forego the locking of partitions which have been pruned. If that patch makes it then the problem will be solved, at least starting with the version the patch makes it into. David
