Re: Horribly slow pg_upgrade performance with many Large Objects

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Nitin Motiani <nitinmotiani(at)google(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-10 21:42:23
Message-ID: aHAzv9pgJh2Wa3M1@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
nathan

Attachment Content-Type Size
v3-0001-pg_upgrade-Use-COPY-for-large-object-metadata.patch text/plain 8.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2025-07-10 22:40:43 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Previous Message Daniel Gustafsson 2025-07-10 21:42:16 Re: Explicitly enable meson features in CI