On Friday, September 15, 2023 9:02 PM Kuroda, Hayato/黒田 隼人 <kuroda.hay...@fujitsu.com> wrote: > > Sorry, wrong patch attached. PSA the correct ones. > There is a possibility that XLOG_PARAMETER_CHANGE may be generated, > when GUC parameters are changed just before doing the upgrade. Added to > list.
I did some simple performance tests for the patch just to make sure it doesn't introduce obvious overhead, the result looks good to me. I tested two cases: 1) The time for upgrade when the old db has 0, 10,50, 100 slots 0 slots(HEAD) : 0m5.585s 0 slots : 0m5.591s 10 slots : 0m5.602s 50 slots : 0m5.636s 100 slots : 0m5.778s 2) The time for upgrade after doing "upgrade --check" in advance, when the old db has 0, 10,50, 100 slots. 0 slots(HEAD) : 0m5.588s 0 slots : 0m5.596s 10 slots : 0m5.605s 50 slots : 0m5.737s 100 slots : 0m5.783s The data of the local machine I used is: CPU(s): 40 Model name: Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz Core(s) per socket: 10 Socket(s): 2 memory: 125GB disk: 6T HDD The old database is empty except for the slots in both tests. The test script is also attached for reference(run perf.sh after adjusting other settings.) Best Regards, Hou zj
<<attachment: perf_script.zip>>