| From: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Hannu Krosing <hannuk(at)google(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Horribly slow pg_upgrade performance with many Large Objects |
| Date: | 2025-07-11 14:19:47 |
| Message-ID: | CAH5HC94tYpgCnoPRYbCGQU0eCM8D7X+aEmB0GZrhjR16JEe5_A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 11, 2025 at 3:12 AM Nathan Bossart <nathandbossart(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-07-11 14:34:33 | Re: Some ExecSeqScan optimizations |
| Previous Message | Konstantin Knizhnik | 2025-07-11 14:19:03 | Re: Logical replication prefetch |