public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tender Wang <[email protected]>
To: David Rowley <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: Add mention in docs about locking all partitions for generic plans
Date: Mon, 24 Mar 2025 17:19:12 +0800
Message-ID: <CAHewXNm2iCGgi4_+WCJ-nnBPKB1q_uXJzSPArHWV_SaDb=gV+Q@mail.gmail.com> (raw)
In-Reply-To: <CAApHDvoRvkmD3z67hY5jb+eEQUyA1QVZBL8_C30HOTjgRhfHzA@mail.gmail.com>
References: <CAApHDvp738G75HfkKcfXaf3a8s=6mmtOLh46tMD0D2hAo1UCzA@mail.gmail.com>
<CAHewXN=BbBCcyxPNBrQsF_Sz+i3n2jPf18rGJQwbbz18yD0J6A@mail.gmail.com>
<CAApHDvoRvkmD3z67hY5jb+eEQUyA1QVZBL8_C30HOTjgRhfHzA@mail.gmail.com>
David Rowley <[email protected]> 于2025年3月24日周一 16:50写道：
> On Mon, 24 Mar 2025 at 19:50, Tender Wang <[email protected]> wrote:
> >
> > David Rowley <[email protected]> 于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
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Add mention in docs about locking all partitions for generic plans
In-Reply-To: <CAHewXNm2iCGgi4_+WCJ-nnBPKB1q_uXJzSPArHWV_SaDb=gV+Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox