út 30. 1. 2024 v 9:14 odesílatel Michael Paquier <mich...@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? > > You may be interested in these threads: > > https://www.postgresql.org/message-id/CAB7nPqTGmNUFi%2BW6F1iwmf7J-o6sY%2Bxxo6Yb%3DmkUVYT-CG-B5A%40mail.gmail.com > > https://www.postgresql.org/message-id/CAB7nPqTys6JUQDxUczbJb0BNW0kPrW8WdZuk11KaxQq6o98PJg%40mail.gmail.com > > 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 I'll read the threads Pavel -- > Michael >
