>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
>I made a rerun of benchmark using "-S -T 30" on the server build with no assertion and
>-O2. The numbers are the best of three successive attempts. The patched version is
>running with cache_target_memory = 0, cache_prune_min_age = 600 and
>cache_entry_limit = 0 but pruning doesn't happen by the workload.
>
>master: 13393 tps
>v12 : 12625 tps (-6%)
>
>Significant degradation is found.
>
>Recuded frequency of dlist_move_tail by taking 1ms interval between two succesive
>updates on the same entry let the degradation dissapear.
>
>patched : 13720 tps (+2%)
It would be good to introduce some interval.
I followed your benchmark (initialized scale factor=10 and others are same option)
and found the same tendency.
These are average of 5 trials.
master: 7640.000538
patch_v12:7417.981378 (3 % down against master)
patch_v13:7645.071787 (almost same as master)
These cases are not pruning happen workload as you mentioned.
I'd like to do benchmark of cache-pruning-case as well.
To demonstrate cache-pruning-case
right now I'm making hundreds of partitioned table and run select query for each partitioned table
using pgbench custom file. Maybe using small number of cache_prune_min_age or hard limit would be better.
Are there any good model?
># I'm not sure the name LRU_IGNORANCE_INTERVAL makes sens..
How about MIN_LRU_UPDATE_INTERVAL?
Regards,
Takeshi Ideriha