| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de> |
| Cc: | "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "alvherre(at)alvh(dot)no-ip(dot)org" <alvherre(at)alvh(dot)no-ip(dot)org>, "michael(dot)paquier(at)gmail(dot)com" <michael(dot)paquier(at)gmail(dot)com>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "craig(at)2ndquadrant(dot)com" <craig(at)2ndquadrant(dot)com> |
| Subject: | RE: Protect syscache from bloating with negative cache entries |
| Date: | 2019-01-22 06:36:18 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FB6D1A4@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp]
> Although this doesn't put a hard cap on memory usage, it is indirectly and
> softly limited by the cache_prune_min_age and cache_memory_target, which
> determins how large a cache can grow until pruning happens. They are
> per-cache basis.
>
> If we prefer to set a budget on all the syschaches (or even including other
> caches), it would be more complex.
>
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2019-01-22 06:48:02 | Re: shared-memory based stats collector |
| Previous Message | Michael Paquier | 2019-01-22 06:35:17 | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |