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.Nasby@BlueTreble.com> wrote in
<6519b7ad-0aa6-c9f4-8869-20691107fb69@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 tablesthat frequently accessed willget benefit from negative
entries,butit might ignorably small. ATTNAME, ATTNUM and RENAMENSP alsomight not get so much from negative entries. If
theseare true,the whole stuff this patch adds can be replaced with just aboolean in cachedesc that inhibits negatvie
entries.Anyway thispatch don't save the case of the cache bloat relaed to functionreference. I'm not sure how that
couldbe reproduced, though.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
