On Mon, 24 Mar 2025 at 19:50, Tender Wang <tndrwang@gmail.com> wrote: > > David Rowley <dgrowleyml@gmail.com> 于2025年3月24日周一 05:28写道： >> 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" .
For that particular case, planning occurs each time prior to execution and it's the planner that takes the lock, not the executor. If you want to not plan each time then you could modify that case to use a plpgsql function instead of sql and then ensure you're using a cached plan with "set plan_cache_mode = force_generic_plan;" (apparently we don't cache plans for non-inlined SQL functions). I disagree that this makes the proposed sentence untrue. 525392d57 did change the order of operations here so that the partitions in the Append/MergeAppend are locked after run-time pruning occurs at executor startup.
Thanks for the explanation.
Maybe I was wrong about writing nothing in master's docs. It might still be important to detail this. I don't know the best way to phrase that, but maybe something along the lines of: "The query planner obtains locks for all partitions which are part of the plan. However, when the executor uses a cached plan, locks are only obtained on the partitions which remain after partition pruning done during the initialization phase of execution, i.e., the ones shown in the EXPLAIN output and not the ones referred to by the “Subplans Removed” property.".
