On Mon, Sep 30, 2019 at 7:39 PM Peter Geoghegan <p...@bowt.ie> wrote: > I've found that my "regular pgbench, but with a low cardinality index > on pgbench_accounts(abalance)" benchmark works best with the specific > heuristics used in the patch, especially over many hours.
I ran pgbench without the pgbench_accounts(abalance) index, and with slightly adjusted client counts -- you could say that this was a classic pgbench benchmark of v20 of the patch. Still scale 500, with single hour runs. Here are the results for each 1 hour run, with client counts of 8, 16, and 32, with two rounds of runs total: master_1_run_8.out: "tps = 25156.689415 (including connections establishing)" patch_1_run_8.out: "tps = 25135.472084 (including connections establishing)" master_1_run_16.out: "tps = 30947.053714 (including connections establishing)" patch_1_run_16.out: "tps = 31225.044305 (including connections establishing)" master_1_run_32.out: "tps = 29550.231969 (including connections establishing)" patch_1_run_32.out: "tps = 29425.011249 (including connections establishing)" master_2_run_8.out: "tps = 24678.792084 (including connections establishing)" patch_2_run_8.out: "tps = 24891.130465 (including connections establishing)" master_2_run_16.out: "tps = 30878.930585 (including connections establishing)" patch_2_run_16.out: "tps = 30982.306091 (including connections establishing)" master_2_run_32.out: "tps = 29555.453436 (including connections establishing)" patch_2_run_32.out: "tps = 29591.767136 (including connections establishing)" This interlaced order is the same order that each 1 hour pgbench run actually ran in. The patch wasn't expected to do any better here -- it was expected to not be any slower for a workload that it cannot really help. Though the two small pgbench indexes do remain a lot smaller with the patch. While a lot of work remains to validate the performance of the patch, this looks good to me. -- Peter Geoghegan
