RE: Protect syscache from bloating with negative cache entries

>From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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