Hello, I have tried to cap the number of negative entries for myself (by removing negative entries in least recentrly created first order) but the ceils cannot be reasonably determined both absolutely or relatively to positive entries. Apparently it differs widely among caches and applications.
At Mon, 23 Jan 2017 08:16:49 -0600, Jim Nasby <jim.na...@bluetreble.com> wrote in <6519b7ad-0aa6-c9f4-8869-20691107f...@bluetreble.com> > On 1/22/17 5:03 PM, Tom Lane wrote: > >> Ok, after reading the code I see I only partly understood what you > >> were > >> saying. In any case, it might still be useful to do some testing with > >> CATCACHE_STATS defined to see if there's caches that don't accumulate > >> a > >> lot of negative entries. > > There definitely are, according to my testing, but by the same token > > it's not clear that a shutoff check would save anything. > > Currently they wouldn't, but there's concerns about the performance of > some of the other ideas in this thread. Getting rid of negative > entries that don't really help could reduce some of those concerns. Or > perhaps the original complaint about STATRELATTINH could be solved by > just disabling negative entries on that cache. As for STATRELATTINH, planning involving small temporary tables that frequently accessed willget benefit from negative entries, but it might ignorably small. ATTNAME, ATTNUM and RENAMENSP also might not get so much from negative entries. If these are true, the whole stuff this patch adds can be replaced with just a boolean in cachedesc that inhibits negatvie entries. Anyway this patch don't save the case of the cache bloat relaed to function reference. I'm not sure how that could be reproduced, though. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
