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