RE: Unnecessary locks for partitioned tables

> <n(dot)kobzarev(at)aeronavigator(dot)ru> writes:
> > Oh, I did not explicitly write that, in case of custom plan (first
attempts or with force_custom_plan) database
> > holds only a couple of locks!
> > Why in this > case it is sufficient to lock only one partition and
parent table ?

> Because partition routing is done at planning time in that case, based on
the actual values of the plan's parameters.
> A generic plan doesn't have the parameter values available, so it has to
build plan nodes for every partition that could conceivably be accessed.
> So for queries of this kind (ie point queries against heavily partitioned
> tables) the generic plan is pretty much always going to lose.
> That doesn't bother me enormously --- there are other query patterns with
similar behavior.

> If you know that your queries always need custom plans, I question the
value of using PREPARE at all.
>
> regards, tom lane

Thank you for your time, Tom.
PREPARE is not mandatory, it is mostly for reproducing purposes. Queries in
stored procedures behaves like prepared statements too, that is expected.
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.

Thanks,
Nikolay