RE: [PoC] pg_upgrade: allow to upgrade publisher node
От | Zhijie Hou (Fujitsu) |
---|---|
Тема | RE: [PoC] pg_upgrade: allow to upgrade publisher node |
Дата | |
Msg-id | OS0PR01MB571665123A4B354552A6F2E194FBA@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: [PoC] pg_upgrade: allow to upgrade publisher node ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: