Re: why there is not VACUUM FULL CONCURRENTLY?
Kirill Reshke <reshkekirill@gmail.com>
From: Kirill Reshke <reshkekirill@gmail.com>
To: Antonin Houska <ah@cybertec.at>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Pavel Stehule <pavel.stehule@gmail.com>, Michael Paquier <michael@paquier.xyz>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-21T15:13:11Z
Lists: pgsql-hackers
Hi! I'm interested in the vacuum concurrently feature being inside the core, so will try to review patch set and give valuable feedback. For now, just a few little thoughts.. > The first version is attached. The actual feature is in 0003. 0004 is probably > not necessary now, but I haven't realized until I coded it. The logical replication vacuum approach is a really smart idea, I like it. As far as I understand, pg_squeeze works well in real production databases, which gives us hope that the vacuum concurrent feature in core will be good too... What is the size of the biggest relation successfully vacuumed via pg_squeeze? Looks like in case of big relartion or high insertion load, replication may lag and never catch up... However, in general, the 3rd patch is really big, very hard to comprehend. Please consider splitting this into smaller (and reviewable) pieces. Also, we obviously need more tests on this. Both tap-test and regression tests I suppose. One more thing is about pg_squeeze background workers. They act in an autovacuum-like fashion, aren't they? Maybe we can support this kind of relation processing in core too?
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