Re: Protect syscache from bloating with negative cache entries

This is a new complete workable patch after a long time of struggling
with benchmarking.

At Tue, 19 Nov 2019 19:48:10 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> I ran the run2.sh script attached, which runs catcachebench2(), which
> asks SearchSysCache3() for cached entries (almost) 240000 times per
> run. The number of each output line is the mean of 3 times runs, and
> stddev. Lines are in "time" order and edited to fit here. "gen_tbl.pl
> | psql" creates a database for the benchmark. catcachebench2() runs
> the shortest path in the three in the attached benchmark program.
>
> (pg_ctl start)
> $ perl gen_tbl.pl | psql ...
> (pg_ctl stop)

I wonder why I took the average of the time instead of choose the
fastest one. This benchmark is extremely CPU intensive so the fastest
run reliably represents the perfromance.

I changed the benchmark so that it shows the time of the fastest run
(run4.sh). Based on the latest result, I used the pattern 3
(SearchSyscacheN indirection, but wrongly pointed as 1 in the last
mail) in the latest version,

I took the number of the fastest time among 3 iteration of 5 runs of
both master/patched O2 binaries.

version | min
---------+---------
master | 7986.65
patched | 7984.47 = 'indirect' below

I would say this version doesn't get degradaded by indirect calls.
So, I applied the other part of the catcache expiration patch as the
succeeding parts. After that I got somewhat strange but very stable
result. Just adding struct members acceleartes the benchmark. The
numbers are the fastest time of 20 runs of the bencmark in 10 times
iterations.

ms
master 7980.79 # the master with the benchmark extension (0001)
=====
base 7340.96 # add only struct members and a GUC variable. (0002)
indirect 7998.68 # call SearchCatCacheN indirectly (0003)
=====
expire-off 7422.30 # CatCache expiration (0004)
# (catalog_cache_prune_min_age = -1)
expire-on 7861.13 # CatCache expiration (catalog_cache_prune_min_age = 0)

The patch accelerates CatCaCheSearch for uncertain reasons. I'm not
sure what makes the difference between about 8000ms and about 7400 ms,
though. Several times building of all versions then running the
benchmark gave me the results with the same tendency. I once stop this
work at this point and continue later. The following files are
attached.

0001-catcache-benchmark-extension.patch:
benchmnark extension used by the benchmarking here. The test tables
are generated using gentbl2.pl attached. (perl gentbk2.pl | psql)

0002-base_change.patch:
Preliminary adds some struct members and a GUC variable to see if
they cause any extent of degradation.

0003-Make-CatCacheSearchN-indirect-functions.patch:
Rewrite to change CatCacheSearchN functions to be called indirectly.

0004-CatCache-expiration-feature.patch:
Add CatCache expiration feature.

gentbl2.pl: A script that emits SQL statements to generate test tables.
run4.sh : The test script I used for benchmarkiing here.
build2.sh : A script I used to build the four types of binaries used here.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center