On Friday, September 15, 2023 9:02 PM Kuroda, Hayato/黒田 隼人 <kuroda.hayato@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
