Re: why there is not VACUUM FULL CONCURRENTLY?
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Michael Paquier <michael@paquier.xyz>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-21T15:23:24Z
Lists: pgsql-hackers
Hi ne 21. 7. 2024 v 17:13 odesílatel Kirill Reshke <reshkekirill@gmail.com> napsal: > 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.. > > > > 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? > I don't think it is necessary when this feature will be an internal feature. I agree so this feature is very important, I proposed it (and I very happy so Tonda implemented it), but I am not sure, if usage of this should be automatized, and if it should be, then a) probably autovacuum should do, b) we can move a discussion after vacuum full concurrently will be merged to upstream, please. Isn't very practical to have too many open targets. Regards Pavel
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