Re: Delay locking partitions during query execution
| От | Amit Langote |
|---|---|
| Тема | Re: Delay locking partitions during query execution |
| Дата | |
| Msg-id | 75b62ff5-45c6-52e0-2d20-8c515442cff8@lab.ntt.co.jp обсуждение исходный текст |
| Ответ на | Re: Delay locking partitions during query execution (David Rowley <david.rowley@2ndquadrant.com>) |
| Ответы |
Re: Delay locking partitions during query execution
|
| Список | pgsql-hackers |
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
In GetCachedPlan:
if (!customplan)
{
if (CheckCachedPlan(plansource))
Thanks,
Amit
В списке pgsql-hackers по дате отправления: