Re: why there is not VACUUM FULL CONCURRENTLY?
От | Kirill Reshke |
---|---|
Тема | Re: why there is not VACUUM FULL CONCURRENTLY? |
Дата | |
Msg-id | CALdSSPg=9Y9sZMymieZoxOT0saVOOhBHv=UfXCjRAZmzDCYzzw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why there is not VACUUM FULL CONCURRENTLY? (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: why there is not VACUUM FULL CONCURRENTLY?
|
Список | 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?
В списке pgsql-hackers по дате отправления: