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  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Следующее
От: Tom Lane
Дата:
Сообщение: PSA: we lack TAP test coverage on NetBSD and OpenBSD