From: David Rowley [mailto:david.rowley@2ndquadrant.com]
> 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.
I think I understood what you mean. Sorry, I don't have a better idea. This unexplanability is probably what we
shouldaccept to avoid the shocking 7% slowdown.
OTOH, how about my original patch that is based on the local lock list? I expect that it won't that significant
slowdownin the same test case. If it's not satisfactory, then v6 is the best to commit.
Regards
Takayuki Tsunakawa
