Re: Horribly slow pg_upgrade performance with many Large Objects - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Horribly slow pg_upgrade performance with many Large Objects
Date
Msg-id Z_RO37whB1L2LbiD@nathan
Whole thread Raw
In response to Horribly slow pg_upgrade performance with many Large Objects  (Hannu Krosing <hannuk@google.com>)
Responses Re: Horribly slow pg_upgrade performance with many Large Objects
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Draft for basic NUMA observability
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER