Re: rebuild big tables with pgrepack - Mailing list pgsql-admin

From Ron Johnson
Subject Re: rebuild big tables with pgrepack
Date
Msg-id CANzqJaB_mC-ArHTg1KBPvf8azEHaw+yfbJci5DX3kPPF2uefBQ@mail.gmail.com
Whole thread Raw
In response to rebuild big tables with pgrepack  (ek ek <livadidrive@gmail.com>)
List pgsql-admin
Possibly triple, since on a test database I noticed that a repack of a 24GB table needed not only the 24 extra GB for the new copy, but also generated 23GB of lz4-compressed WAL files in the pgbackrest archive.

Of course, if that 900GB table is mostly empty, you'll only need triple the "actually used" space.

On Mon, Nov 24, 2025 at 6:26 AM Shardul Borhade <shardul@dbtune.com> wrote:
Hi Ron,

So basically, we need to have twice the space of the table and its indexes available before performing a repack, right?

On Fri, Nov 14, 2025 at 8:47 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Fri, Nov 14, 2025 at 2:14 PM ek ek <livadidrive@gmail.com> wrote:
Hello everyone,
I’m going to rebuild a 900GB table using pg_repack. I’m hesitant to do such a large operation in one go.
Is there an ideal or recommended way to repack very large tables?

Everything in database maintenance is circumstantial.

The basics that I'd do are:
* Verify that you have enough free disk space for both the new table, the new indices and also the WALs generated.
* Do it during a low-activity window.
* Don't run a database backup at the same time.
* First execute with --dry-run.
* Consider the --no-order option.  That'll speed things up.
* And --no-analyze, though you'll have to manually ANALYZE immediately afterwards.
* (I'd probably disable autoanalyze on that table before the repack and then enable it after the manual ANALYZE.)
* The --jobs option speeds up index rebuilds.
* Run it from cron, and redirect both stdout and stderr to the same log file.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!


--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

pgsql-admin by date:

Previous
From: Kasper Føns
Date:
Subject: restore_command on high-throughput cluster never switches to streaming replication
Next
From: Ron Johnson
Date:
Subject: Is the pg_isready database name relevant?