Re: pg_dump -Z6 (the default) can be pretty slow - Mailing list pgsql-admin

From Ron
Subject Re: pg_dump -Z6 (the default) can be pretty slow
Date
Msg-id 45e16ff2-da2d-46c3-be52-03cad8eb60a3@gmail.com
Whole thread Raw
In response to Re: pg_dump -Z6 (the default) can be pretty slow  (Scott Ribe <scott_ribe@elevated-dev.com>)
List pgsql-admin
On 10/18/23 18:42, Scott Ribe wrote:
On Oct 18, 2023, at 5:21 PM, Ron <ronljohnsonjr@gmail.com> wrote:

It didn't occur to me to mention that I used it.  Do people really still not use -Fd?
I don't know--I guess it depends on context. Certainly for upgrades I don't know any reason not to.

Even for nightly backups (we still use pg_dump instead of pgbackrest on a few smaller systems), I always use directory format backups.

I'm still using 9.6, so that feature isn't available yet.  When I get the Pg 15 VMs stood up (Pg15 binaries are not available for RHEL 6), I'm definitely going to try that.
I thought of that mere seconds after posting my prior reply ;-)

Have you considered pg_upgrade?

Since "the migrated databases will be on new servers, and we purge off old partitions and add new partitions, pg_upgrade and logical replication are off the table".

And, of course, 9.6 binaries aren't available at all (at least I can't find 9.6.24 RPMs anywhere under https://download.postgresql.org/pub/), so rsyncing the database files to the new server and then doing a pg_upgrade won't work.  Even then, I'd have to rebuild many indices anyway, due to glibc locale changes.



--
Born in Arizona, moved to Babylonia.

pgsql-admin by date:

Previous
From: Scott Ribe
Date:
Subject: Re: pg_dump -Z6 (the default) can be pretty slow
Next
From: Julien Rouhaud
Date:
Subject: Re: Tools available to determine bad code in the testing phase