RE: Protect syscache from bloating with negative cache entries - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Protect syscache from bloating with negative cache entries
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB70EFB@G01JPEXMBYT05
Whole thread Raw
In response to Re: Protect syscache from bloating with negative cache entries  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Protect syscache from bloating with negative cache entries  ('Bruce Momjian' <bruce@momjian.us>)
Re: Protect syscache from bloating with negative cache entries  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Hi Horiguchi-san, Bruce,

From: Bruce Momjian [mailto:bruce@momjian.us]
> 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.

Please forgive me if I say something silly (I might have got lost.)

Are you suggesting to make the cache size limit system-defined and uncontrollable by the user?  I think it's necessary
forthe DBA to be able to control the cache memory amount.  Otherwise, if many concurrent connections access many
partitionswithin a not-so-long duration, then the cache eviction can't catch up and ends up in OOM.  How about the
followingquestions I asked in my previous mail?
 

--------------------------------------------------
This is a pure question.  How can we answer these questions from users?

* What value can I set to cache_memory_target when I can use 10 GB for the caches and max_connections = 100?
* How much RAM do I need to have for the caches when I set cache_memory_target = 1M?

The user tends to estimate memory to avoid OOM.
--------------------------------------------------


Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Protect syscache from bloating with negative cache entries
Next
From: Pavel Stehule
Date:
Subject: Re: proposal - plpgsql unique statement id