MIME-Version: 1.0
References: <202512151349.vlq3mpfniyk3@alvherre.pgsql> <11247.1767609087@localhost>
 <11558.1767609632@localhost> <141054.1767891540@localhost>
 <CADzfLwU-OmxW3t3AoQo9=K7uq4G1yZ-txcetzW3jbcVxV_pJew@mail.gmail.com>
 <137668.1768235610@localhost> <CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com>
 <CADzfLwXJ+4s1tJuG9injcxAUP3urj9D6dUAPOCaX33UeiUxrRQ@mail.gmail.com>
 <74802.1769071060@localhost> <CADzfLwVZ_DeU_3avD=G4ZHFJJgZ0EOFzxnmWxwyB23zsS-uxjA@mail.gmail.com>
 <CADzfLwUEH5+LjCN+6kRfSsXwuou8rKXyVV42Wi-O_TG0360Kug@mail.gmail.com>
 <3901.1769412880@localhost> <88003.1769511456@localhost> <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com>
 <5367.1770017148@localhost>
In-Reply-To: <5367.1770017148@localhost>
From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Date: Mon, 2 Feb 2026 10:18:01 +0100
Message-ID: <CADzfLwXmkRKc5jBCUT+vZ3hHOtyz7+Daa5tQ9Qnj+x8-ZuuKWw@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Antonin Houska <ah@cybertec.at>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, 
	Pg Hackers <pgsql-hackers@lists.postgresql.org>, Robert Treat <rob@xzilla.net>
Content-Type: multipart/alternative; boundary="000000000000ebba260649d3cee0"
Archived-At: <https://www.postgresql.org/message-id/CADzfLwXmkRKc5jBCUT%2BvZ3hHOtyz7%2BDaa5tQ9Qnj%2Bx8-ZuuKWw%40mail.gmail.com>
Precedence: bulk

--000000000000ebba260649d3cee0
Content-Type: text/plain; charset="UTF-8"

Helllo!

> I don't really pay attention to pg_repack, but I do pay quite some
attention
> to the pg_squeeze extension (which I wrote and maintain). I recall that
some
> users were surprised by the amount of disk space consumed (as the earlier
> versions of pg_squeeze were "too lazy" about WAL decoding), but I do not
> recall a single complaint about pg_squeeze causing the XID wraparound
> situation.

For "finish" I mean get out of space (in other write-heavy tables) or high
CPU usage (due to slow index scan checking the same rows again and again).
Also, you REPACK one table - and add a lot of bloat in others, in some
cases with negative impact in total.

But yes, agree about pg_squeeze here - if it is usable with such a long
transaction - REPACK CONCURRENTLY will be too.

Mikhail.

--000000000000ebba260649d3cee0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Helllo!</div><div><br></div><div>&gt=
; I don&#39;t really pay attention to pg_repack, but I do pay quite some at=
tention<br>&gt;=C2=A0to the pg_squeeze extension (which I wrote and maintai=
n). I recall that some<br>&gt;=C2=A0users were surprised by the amount of d=
isk space consumed (as the earlier<br>&gt;=C2=A0versions of pg_squeeze were=
 &quot;too lazy&quot; about WAL decoding), but I do not<br>&gt;=C2=A0recall=
 a single complaint about pg_squeeze causing the XID wraparound<br>&gt;=C2=
=A0situation.<br></div><div><br></div><div>For &quot;finish&quot; I mean ge=
t out of space (in other write-heavy tables) or high CPU usage (due to slow=
 index scan checking the same rows again and again).</div><div>Also, you RE=
PACK one table - and add a lot of bloat in others, in some cases with negat=
ive=C2=A0impact in total.</div><div><br></div><div>But yes, agree about pg_=
squeeze here - if it is usable with such a long transaction - REPACK CONCUR=
RENTLY will be too.</div><div><br></div><div>Mikhail.</div></div>
</div>

--000000000000ebba260649d3cee0--