←back to thread

366 points virtualwhys | 3 comments | | HN request time: 0.205s | source
1. thr0w ◴[] No.41898232[source]
Don't agree with their characterization of `pg_repack`. `VACUUM FULL` is definitely crushing, but that's why repack exists as a faster/lighter alternative. Anyone have a different experience?
replies(2): >>41898486 #>>41899466 #
2. dfox ◴[] No.41898486[source]
pg_repack is an hack-ish solution to do what VACUUM FULL does without completely locking the relation in question. But well, when you care about either of these things, your workload has significant issues, with the typical case being using pgsql as a backend for something that was originally a thick client designed for some kind of RDBMS based on shared files (InterBase mentioned in TFA, MS Jet whatever…)
3. fovc ◴[] No.41899466[source]
The requirement for having two copies of the table simultaneously on systems that make it easy to add but not subtract storage. Otherwise pg_repack has worked really well.

We solved the 2x storage with partitions, but it feels like the tail wagging the dog