>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > > >(2) Another new patch v15-0005 on top of previous design of > limit-by-number-of-a-cache feature converts it to > limit-by-size-on-all-caches feature, which I think is > Tsunakawa-san wanted. Yeah, size looks better to me.
>As far as I can see no significant degradation is found in usual (as long as >pruning >doesn't happen) code paths. > >About the new global-size based evicition(2), cache entry creation becomes >slow after >the total size reached to the limit since every one new entry evicts one or >more old (= >not-recently-used) entries. Because of not needing knbos for each cache, it >become >far realistic. So I added documentation of "catalog_cache_max_size" in 0005. Now I'm also trying to benchmark, which will be posted in another email. Here are things I noticed: [1] compiler warning catcache.c:109:1: warning: missing braces around initializer [-Wmissing-braces] dlist_head cc_lru_list = {0}; ^ catcache.c:109:1: warning: (near initialization for ‘cc_lru_list.head’) [-Wmissing-braces] [2] catalog_cache_max_size is not appered in postgresql.conf.sample [3] global lru list and global size can be included in CatCacheHeader, which seems to me good place because this structure contains global cache information regardless of kind of CatCache [4] when applying patch with git am, there are several warnings about trailing white space at v15-0003 Regards, Takeshi Ideriha