At Wed, 30 Jan 2019 05:06:30 +0000, "Ideriha, Takeshi" <ideriha.take...@jp.fujitsu.com> wrote in <4E72940DA2BF16479384A86D54D0988A6F4156D4@G01JPEXMBKW04> > >You don't have a direct control on syscache memory usage. When you find a > >queriy > >slowed by the default cache expiration, you can set cache_memory_taret to > >keep > >them for intermittent execution of a query, or you can increase > >syscache_prune_min_age to allow cache live for a longer time. > > In current ver8 patch there is a stats view representing age class > distribution. > https://www.postgresql.org/message-id/20181019.173457.68080786.horiguchi.kyotaro%40lab.ntt.co.jp > Does it help DBA with tuning cache_prune_age and/or cache_prune_target?
Definitely. At least DBA can see nothing about cache usage. > If the amount of cache entries of older age class is large, are people > supposed to lower prune_age and > not to change cache_prune_target? > (I get confusion a little bit.) This feature just removes cache entries that have not accessed for a certain time. If older entries occupies the major portion, it means that syscache is used effectively (in other words most of the entries are accessed frequently enough.) And in that case I believe syscache doesn't put pressure to memory usage. If the total memory usage exceeds expectations in the case, reducing pruning age may reduce it but not necessarily. Extremely short pruning age will work in exchange for performance degradation. If newer entries occupies the major portion, it means that syscache may not be used effectively. The total amount of memory usage will be limited by puruning feature so tuning won't be needed. In both cases, if pruning causes slowdown of intermittent large queries, cache_memory_target will alleviate the slowdown. regards. -- Kyotaro Horiguchi NTT Open Source Software Center