On Thu, 10 Nov 2022 at 04:11, <n.kobzarev@aeronavigator.ru> 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
