Re: why there is not VACUUM FULL CONCURRENTLY?
Kirill Reshke <reshkekirill@gmail.com>
From: Kirill Reshke <reshkekirill@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-25T10:02:28Z
Lists: pgsql-hackers
Hi! On Tue, 30 Jan 2024 at 15:31, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > FWIW a newer, more modern and more trustworthy alternative to pg_repack > is pg_squeeze, which I discovered almost by random chance, and soon > discovered I liked it much more. Can you please clarify this a bit more? What is the exact reason for pg_squeeze being more trustworthy than pg_repack? Is there something about the logical replication approach that makes it more bulletproof than the trigger-based repack approach? Also, I was thinking about pg_repack vs pg_squeeze being used for the VACUUM FULL CONCURRENTLY feature, and I'm a bit suspicious about the latter. If I understand correctly, we essentially parse the whole WAL to obtain info about one particular relation changes. That may be a big overhead, whereas the trigger approach does not suffer from this. So, there is the chance that VACUUM FULL CONCURRENTLY will never keep up with vacuumed relation changes. Am I right?
Commits
-
Add CONCURRENTLY option to REPACK
- 28d534e2ae0a 19 (unreleased) landed
-
Introduce the REPACK command
- ac58465e0618 19 (unreleased) landed
-
Adjust signature of cluster_rel() and its subroutines
- cc811f92bac5 18.0 landed
-
Simplify signature of RewriteTable
- ebd8fc7e47fd 18.0 cited