Re: Delay locking partitions during query execution

On Thu, 17 Jan 2019 at 17:18, Amit Langote
<Langote_Amit_f8@lab.ntt.co.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