>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@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