From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: why there is not VACUUM FULL CONCURRENTLY? |
Date: | 2024-07-25 10:02:28 |
Message-ID: | CALdSSPg=9Y9sZMymieZoxOT0saVOOhBHv=UfXCjRAZmzDCYzzw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Tue, 30 Jan 2024 at 15:31, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-07-25 10:10:58 | Re: Logical Replication of sequences |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-07-25 09:58:03 | RE: Parallel heap vacuum |