út 30. 1. 2024 v 9:14 odesílatel Michael Paquier <michael@paquier.xyz> napsal:
On Tue, Jan 30, 2024 at 09:01:57AM +0100, Pavel Stehule wrote: > I have one question, what is a block of implementation of some variant of > VACUUM FULL like REINDEX CONCURRENTLY? Why similar mechanism of REINDEX > CONCURRENTLY cannot be used for VACUUM FULL?
VACUUM FULL is CLUSTER under the hoods. One may question whether it is still a relevant discussion these days if we assume that autovacuum is able to keep up, because it always keeps up with the house cleanup, right? ;)
More seriously, we have a lot more options these days with VACUUM like PARALLEL, so CONCURRENTLY may still have some uses, but the new toys available may have changed things. So, would it be worth the complexities around heap manipulations that lower locks would require?
One of my customer today is reducing one table from 140GB to 20GB. Now he is able to run archiving. He should play with pg_repack, and it is working well today, but I ask myself, what pg_repack does not be hard to do internally because it should be done for REINDEX CONCURRENTLY. This is not a common task, and not will be, but on the other hand, it can be nice to have feature, and maybe not too hard to implement today. But I didn't try it
