Re: speeding up planning with partitions
От | Amit Langote |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | 5b76aea7-2785-f3d0-4184-3039eddab8ba@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | RE: speeding up planning with partitions ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
RE: speeding up planning with partitions
|
Список | pgsql-hackers |
Tsunakawa-san, On 2019/01/18 14:12, Tsunakawa, Takayuki wrote: > From: Amit Langote [mailto:Langote_Amit_f8@lab.ntt.co.jp] >> Are you saying that, when using auto mode, all executions of the query >> starting from 7th are slower than the first 5 executions? That is, the >> latency of creating and using a custom plan increases *after* a generic >> plan is created and discarded on the 6th execution of the query? If so, >> that is inexplicable to me. > > Isn't CheckCachedPlan() (and AcquireExecutorLocks() therein) called in every EXECUTE after 6th one due to some unknow issue? CheckCachedPlan is only called if choose_custom_plan() returns false resulting in generic plan being created/reused. With plan_cache_mode = auto, I see it always returns true, because a custom plan containing a single partition to scan is way cheaper than the generic plan. > Does choose_custom_plan() always return true after 6th EXECUTE? Yes. Thanks, Amit
В списке pgsql-hackers по дате отправления: