| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-02-02 09:18:01 |
| Message-ID: | CADzfLwXmkRKc5jBCUT+vZ3hHOtyz7+Daa5tQ9Qnj+x8-ZuuKWw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jakub Wartak | 2026-02-02 09:22:37 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Previous Message | Mihail Nikalayeu | 2026-02-02 09:17:42 | Re: Adding REPACK [concurrently] |