>From: Kyotaro HORIGUCHI [mailto:[email protected]]
>
>
>(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
