On Mon, 22 Jul 2019 at 12:48, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > > From: David Rowley [mailto:david.row...@2ndquadrant.com] > > I went back to the drawing board on this and I've added some code that > > counts > > the number of times we've seen the table to be oversized and just shrinks > > the table back down on the 1000th time. 6.93% / 1000 is not all that much. > > I'm afraid this kind of hidden behavior would appear mysterious to users. > They may wonder "Why is the same query fast at first in the session (5 or 6 > times of execution), then gets slower for a while, and gets faster again? Is > there something to tune? Am I missing something wrong with my app (e.g. how > to use prepared statements)?" So I prefer v5.
Another counter-argument to this is that there's already an unexplainable slowdown after you run a query which obtains a large number of locks in a session or use prepared statements and a partitioned table with the default plan_cache_mode setting. Are we not just righting a wrong here? Albeit, possibly 1000 queries later. I am, of course, open to other ideas which solve the problem that v5 has, but failing that, I don't see v6 as all that bad. At least all the logic is contained in one function. I know Tom wanted to steer clear of heuristics to reinitialise the table, but most of the stuff that was in the patch back when he complained was trying to track the average number of locks over the previous N transactions, and his concerns were voiced before I showed the 7% performance regression with unconditionally rebuilding the table. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
