Re: Horribly slow pg_upgrade performance with many Large Objects
| От | Nitin Motiani |
|---|---|
| Тема | Re: Horribly slow pg_upgrade performance with many Large Objects |
| Дата | |
| Msg-id | CAH5HC94tYpgCnoPRYbCGQU0eCM8D7X+aEmB0GZrhjR16JEe5_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Horribly slow pg_upgrade performance with many Large Objects (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: Horribly slow pg_upgrade performance with many Large Objects
|
| Список | pgsql-hackers |
On Fri, Jul 11, 2025 at 3:12 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote:
> - * pg_largeobject_metadata, after the dump is restored.
> + * pg_largeobject_metadata, after the dump is restored. In versions
> + * before v12, this is done via proper large object commands. In
> + * newer versions, we dump the content of pg_largeobject_metadata and
> + * any associated pg_shdepend rows, which is faster to restore.
> */
>
> Should the comment provide further detail on why this is only being done
> for v12 and above?
Yes. I've fixed this in v3.
Thanks. Looks good to me. Also just would like to confirm that the pg_dump_sort change will go in a different patch.
Regards,
Nitin Motiani
Google
В списке pgsql-hackers по дате отправления: