RE: Speed up transaction completion faster after many relations areaccessed in a transaction

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