Re: Delay locking partitions during query execution

On Thu, 17 Jan 2019 at 17:18, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> On 2019/01/04 9:53, David Rowley wrote:
> > Without PREPAREd statements, if the planner itself was unable to prune
> > the partitions it would already have obtained the lock during
> > planning, so AcquireExecutorLocks(), in this case, would bump into the
> > local lock hash table entry and forego trying to obtain the lock
> > itself. That's not free, but it's significantly faster than obtaining
> > a lock.
>
> Hmm, AcquireExecutorLocks is only called if prepared statements are used
> and that too if a generic cached plan is reused.
>
> GetCachedPlan -> CheckCachedPlan -> AcquireExecutorLocks

ah okay. Thanks for the correction, but either way, it's really only
useful when run-time pruning prunes partitions before initialising the
Append/MergeAppend node.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services