Re: pg_upgrade failing for 200+ million Large Objects
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade failing for 200+ million Large Objects |
Дата | |
Msg-id | 3023817.1710629175@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade failing for 200+ million Large Objects (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: pg_upgrade failing for 200+ million Large Objects
Re: pg_upgrade failing for 200+ million Large Objects |
Список | pgsql-hackers |
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Fri, 2024-03-15 at 19:18 -0400, Tom Lane wrote: >> This patch seems to have stalled out again. In hopes of getting it >> over the finish line, I've done a bit more work to address the two >> loose ends I felt were probably essential to deal with: > Applies and builds fine. > I didn't scrutinize the code, but I gave it a spin on a database with > 15 million (small) large objects. I tried pg_upgrade --link with and > without the patch on a debug build with the default configuration. Thanks for looking at it! > Without the patch: > Runtime: 74.5 minutes > With the patch: > Runtime: 70 minutes Hm, I'd have hoped for a bit more runtime improvement. But perhaps not --- most of the win we saw upthread was from parallelism, and I don't think you'd get any parallelism in a pg_upgrade with all the data in one database. (Perhaps there is more to do there later, but I'm still not clear on how this should interact with the existing cross-DB parallelism; so I'm content to leave that question for another patch.) regards, tom lane
В списке pgsql-hackers по дате отправления: