Re: speeding up planning with partitions - Mailing list pgsql-hackers

From Amit Langote
Subject Re: speeding up planning with partitions
Date
Msg-id 5b76aea7-2785-f3d0-4184-3039eddab8ba@lab.ntt.co.jp
Whole thread Raw
In response to RE: speeding up planning with partitions  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: speeding up planning with partitions  ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: problems with foreign keys on partitioned tables
Next
From: Michael Paquier
Date:
Subject: Simplify set of flags used by MyXactFlags