Re: Horribly slow pg_upgrade performance with many Large Objects
| От | Nathan Bossart |
|---|---|
| Тема | Re: Horribly slow pg_upgrade performance with many Large Objects |
| Дата | |
| Msg-id | Z_VE4Q4A2nNCX3Ny@nathan обсуждение исходный текст |
| Ответ на | Re: Horribly slow pg_upgrade performance with many Large Objects (Hannu Krosing <hannuk@google.com>) |
| Ответы |
Re: Horribly slow pg_upgrade performance with many Large Objects
Re: Horribly slow pg_upgrade performance with many Large Objects |
| Список | pgsql-hackers |
On Tue, Apr 08, 2025 at 09:35:24AM +0200, Hannu Krosing wrote: > On Tue, Apr 8, 2025 at 12:17 AM Nathan Bossart <nathandbossart@gmail.com> wrote: >> That being said, I >> regularly hear about slow upgrades with many LOs, so I think it'd be >> worthwhile to try to improve matters in v19. > > Changing the LO export to dumping pg_largeobject_metadata content > instead of creating the LOs should be a nice small change confined to > pg_dump --binary-upgrade only so perhaps we could squeeze it in v18 > still. Feature freeze for v18 was ~4 hours ago, so unfortunately this is v19 material at this point. -- nathan
В списке pgsql-hackers по дате отправления: