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 https://www.postgresql.org/message-id/CAKJS1f_ycJ-6QTKC70pZRYdwsAwUo+t0_CV0eXC=j-b5a2m...@mail.gmail.com 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
