David Rowley <dgrowle...@gmail.com> 于2025年3月24日周一 05:28写道：
> Over in [1], there was some uncertainty about whether locking an > unrelated partition was expected behaviour or not for the particular > use-case which used a generic plan to scan a partitioned table and all > of the partitions. > > I noticed that we don't mention this in the docs and though that > perhaps we should. I thought a good place might be in [2] at the end > of the following paragraph: > > "During initialization of the query plan. Partition pruning can be > performed here for parameter values which are known during the > initialization phase of execution. Partitions which are pruned during > this stage will not show up in the query's EXPLAIN or EXPLAIN ANALYZE. > It is possible to determine the number of partitions which were > removed during this phase by observing the “Subplans Removed” property > in the EXPLAIN output." > > Perhaps adding something like "Because all relations which are part of > the plan are locked at the beginning of execution, any partitions > pruned at this stage are already locked and will remain so until the > end of the transaction.". > > or: > > "It's important to note that any partitions removed by the partition > pruning done at this stage are still locked at the beginning of > execution". > I prefer this. > > This is no longer true in master, so if we do something here it's only > v17 and earlier. > In the case of [1], we still have AccessShareLock on entity_2, even though it is pruned during initial partition pruning. This seems to contradict what you said. "This is no longer true in master" . [1] https://postgr.es/m/01020195b987abd3-a008b77d-8c63-4931-80a4-be36a351c8b2-000...@eu-west-1.amazonses.com -- Thanks, Tender Wang
