Re: Protect syscache from bloating with negative cache entries

At Tue, 26 Feb 2019 10:55:18 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+Tgmoa2b-LUF9h3wugD9ZA5MP0xyu2kJYHC9L6sdLywNSmhBQ(at)mail(dot)gmail(dot)com>
> On Mon, Feb 25, 2019 at 1:27 AM Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > > I'd like to see some evidence that catalog_cache_memory_target has any
> > > value, vs. just always setting it to zero.
> >
> > It is artificial (or acutually wont't be repeatedly executed in a
> > session) but anyway what can get benefit from
> > catalog_cache_memory_target would be a kind of extreme.
>
> I agree. So then let's not have it.

Ah... Yeah! I see. Andres' concern was that crucial syscache
entries might be blown away during a long idle time. If that
happens, it's enough to just turn off in the almost all of such
cases.

We no longer need to count memory usage without the feature. That
sutff is moved to monitoring feature, which is out of the scope
of the current status of this patch.

> We shouldn't add more mechanism here than actually has value. It
> seems pretty clear that keeping cache entries that go unused for long
> periods can't be that important; even if we need them again
> eventually, reloading them every 5 or 10 minutes can't hurt that much.
> On the other hand, I think it's also pretty clear that evicting cache
> entries that are being used frequently will have disastrous effects on
> performance; as I noted in the other email I just sent, consider the
> effects of CLOBBER_CACHE_ALWAYS. No reasonable user is going to want
> to incur a massive slowdown to save a little bit of memory.
>
> I see that *in theory* there is a value to
> catalog_cache_memory_target, because *maybe* there is a workload where
> tuning that GUC will lead to better performance at lower memory usage
> than any competing proposal. But unless we can actually see an
> example of such a workload, which so far I don't, we're adding a knob
> that everybody has to think about how to tune when in fact we have no
> idea how to tune it or whether it even needs to be tuned. That
> doesn't make sense. We have to be able to document the parameters we
> have and explain to users how they should be used. And as far as this
> parameter is concerned I think we are not at that point.

In the attached v18,
catalog_cache_memory_target is removed,
removed some leftover of removing the hard limit feature,
separated catcache clock update during a query into 0003.
attached 0004 (monitor part) in order just to see how it is working.

v18-0001-Add-dlist_move_tail:
Just adds dlist_move_tail

v18-0002-Remove-entries-that-haven-t-been-used-for-a-certain-:
Revised pruning feature.

====
v18-0003-Asynchronous-update-of-catcache-clock:
Separated catcache clock update feature.

v18-0004-Syscache-usage-tracking-feature:
Usage tracking feature.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center