From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | 杨伯宇(长堂) <yangboyu(dot)yby(at)alibaba-inc(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: 回复:Re: speed up pg_upgrade with large number of tables |
Date: | 2024-07-05 15:12:34 |
Message-ID: | ZogNYtkXvYVAMGAf@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 05, 2024 at 05:24:42PM +0800, 杨伯宇(长堂) wrote:
>> > So, I'm thinking, why not add a "--skip-check" option in pg_upgrade to skip it?
>> > See "1-Skip_Compatibility_Check_v1.patch".
>>
>> How would a user know that nothing has changed in the cluster between running
>> the check and running the upgrade with a skipped check? Considering how
>> complicated it is to understand exactly what pg_upgrade does it seems like
>> quite a large caliber footgun.
I am also -1 on this one for the same reasons as Daniel.
>> I would be much more interested in making the check phase go faster, and indeed
>> there is ongoing work in this area. Since it sounds like you have a dev and
>> test environment with a big workload, testing those patches would be helpful.
>> https://commitfest.postgresql.org/48/4995/ is one that comes to mind.
> Very meaningful work! I will try it.
Thanks! Since you mentioned that you have multiple databases with 1M+
databases, you might also be interested in commit 2329cad. That should
speed up the pg_dump step quite a bit.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | feichanghong | 2024-07-05 15:19:22 | Optimize commit performance with a large number of 'on commit delete rows' temp tables |
Previous Message | Erik Wienhold | 2024-07-05 14:41:39 | Re: XML test error on Arch Linux |