From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Delay locking partitions during query execution |
Date: | 2019-01-17 09:08:40 |
Message-ID: | CAKJS1f8m-q=b9sxiB-vP7WoY4DXT7Kfk4NaM5U4-UJM91M36nQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2019-01-17 09:28:48 | Re: add_partial_path() may remove dominated path but still in use |
Previous Message | Peter Eisentraut | 2019-01-17 08:41:50 | Re: log bind parameter values on error |