Re: pg_dump -Z6 (the default) can be pretty slow

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump -Z6 (the default) can be pretty slow
Date: 2023-10-19 00:00:31
Message-ID: 45e16ff2-da2d-46c3-be52-03cad8eb60a3@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 10/18/23 18:42, Scott Ribe wrote:
>> On Oct 18, 2023, at 5:21 PM, Ron<ronljohnsonjr(at)gmail(dot)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.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Julien Rouhaud 2023-10-19 04:25:58 Re: Tools available to determine bad code in the testing phase
Previous Message Scott Ribe 2023-10-18 23:42:51 Re: pg_dump -Z6 (the default) can be pretty slow