Re: Horribly slow pg_upgrade performance with many Large Objects

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Nitin Motiani <nitinmotiani@google.com>
Cc: Hannu Krosing <hannuk@google.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-10T21:42:23Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. pg_upgrade: Use COPY for large object metadata.

  2. pg_dump: Fix object-type sort priority for large objects.

  3. pg_upgrade: Mention that we preserve database OIDs in a comment.

  4. pg_upgrade: Preserve database OIDs.

  5. Fix pg_upgrade for oid removal.

Attachments

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