On Mon, 22 Jul 2019 at 16:36, Tsunakawa, Takayuki
<tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> > For the use case we've been measuring with partitioned tables and the
> > generic plan generation causing a sudden spike in the number of
> > obtained locks, then having plan_cache_mode = force_custom_plan will
> > cause the lock table not to become bloated. I'm not sure there's
> > anything interesting to measure there.
> I meant the difference between the following two cases, where the query only 
> touches one partition (e.g. SELECT ... WHERE pkey = value):
> * plan_cache_mode=force_custom_plan: LocalLockHash won't bloat.  The query 
> execution time is steady.
> * plan_cache_mode=auto: LocalLockHash bloats on the sixth execution due to 
> the creation of the generic plan.  The generic plan is not adopted because 
> its cost is high.  Later executions of the query will suffer from the bloat 
> until the 1006th execution when LocalLockHash is shrunk.

I measured this again in
where I posted the v6 patch.  It's the final results in the email.   I
didn't measure plan_cache_mode = force_custom_plan. There'd be no lock
table bloat in that case and the additional overhead would just be
from the hash_get_num_entries() && hash_get_max_bucket() calls, which
the first results show next to no overhead for.

 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to