Re: Protect syscache from bloating with negative cache entries

On Thu, Jan 24, 2019 at 06:39:24PM +0900, Kyotaro HORIGUCHI wrote:
> > Second, when would you use syscache_memory_target != 0?
>
> It is a suggestion upthread, we sometimes want to keep some known
> amount of caches despite that expration should be activated.
>
> > If you had
> > syscache_prune_min_age really fast, e.g. 10 seconds? What is the
> > use-case for this? You have a query that touches 10k objects, and then
> > the connection stays active but doesn't touch many of those 10k objects,
> > and you want it cleaned up in seconds instead of minutes? (I can't see
> > why you would not clean up all unreferenced objects after _minutes_ of
> > disuse, but removing them after seconds of disuse seems undesirable.)
> > What are the odds you would retain the entires you want with a fast
> > target?
>
> Do you asking the reason for the unit? It's just because it won't
> be so large even in seconds, to the utmost 3600 seconds. Even
> though I don't think such a short dutaion setting is meaningful
> in the real world, either I don't think we need to inhibit
> that. (Actually it is useful for testing:p) Another reason is

We have gone from ignoring the cache bloat problem to designing an API
that even we don't know what value they provide, and if we don't know,
we can be sure our users will not know. Every GUC has a cost, even if
it is not used.

I suggest you go with just syscache_prune_min_age, get that into PG 12,
and we can then reevaluate what we need. If you want to hard-code a
minimum cache size where no pruning will happen, maybe based on the system
catalogs or typical load, that is fine.

> that GUC_UNIT_MIN doesn't seem so common that it is used only by
> two variables, log_rotation_age and old_snapshot_threshold.
>
> > What is the value of being able to change a specific backend's stat
> > interval? I don't remember any other setting having this ability.
>
> As mentioned upthread, it takes significant time to take
> statistics so I believe no one is willing to turn it on at all
> times. As the result it should be useless because it cannot be
> turned on on an active backend when it actually gets bloat. So I
> wanted to provide a remote switching feture.
>
> I also thought that there's some other features that is useful if
> it could be turned on remotely so the remote GUC feature but it
> was too complex...

Well, I am thinking if we want to do something like this, we should do
it for all GUCs, not just for this one, so I suggest we not do this now
either.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +