Re: Horribly slow pg_upgrade performance with many Large Objects
В списке pgsql-hackers по дате отправления:
| От | Nathan Bossart |
|---|---|
| Тема | Re: Horribly slow pg_upgrade performance with many Large Objects |
| Дата | |
| Msg-id | Z_RO37whB1L2LbiD@nathan обсуждение |
| Ответ на | Horribly slow pg_upgrade performance with many Large Objects (Hannu Krosing <hannuk@google.com>) |
| Ответы |
Re: Horribly slow pg_upgrade performance with many Large Objects
|
| Список | pgsql-hackers |
On Mon, Apr 07, 2025 at 10:33:47PM +0200, Hannu Krosing wrote: > The obvious solution would be to handle the table > `pg_largeobject_metadata` the same way as we currently handle > `pg_largeobject `by not doing anything with it in `pg_dump > --binary-upgrade` and just handle the contents it like we do for user > tables in pg_upgrade itself. > > This should work fine for all source database versions starting from PgSQL v12. Unfortunately, the storage format for aclitem changed in v16, so this would need to be restricted to upgrades from v16 and newer. 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. -- nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера