> <n.kobzarev@xxxxxxxxxxxxxxxx> 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
