David Rowley <dgrowle...@gmail.com> 于2025年3月24日周一 16:50写道：
> On Mon, 24 Mar 2025 at 19:50, Tender Wang <tndrw...@gmail.com> wrote: > > > > David Rowley <dgrowle...@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.". > > Any opinions? > The above sentence looks good to me. -- Thanks, Tender Wang
