We looked at adding support for this on Crunchy Bridge, and at the time opt'ed for pg_repack as it seemed bit like too much complexity and magic going on with automatically running and the background worker. The promise of automatically and proactively managing bloat is definitely an exciting one so optimistic to see it continue to improve and evolve. We'll personally probably take a fresh look next year, but for now pg_repack has definitely been a big win for users.
back
1 comments
I used pg_repack at a very large scale, and one issue I ran into was write amplification. Since it used triggers to keep a log of rows changed, writes during repack were 2x normal.
pg_squeeze use of replication slots seems cool because it just tells Postgres to save WAL it already wrote, no 2x amplification.
Good point.
I wonder if pg_squeeze would work well in a large-scale heavy-writes case. There is a very sad and hard limit of single-threaded walsender that can saturate a single core (depends on CPU and schema / writes complexity; for example, I saw systems where it happened at ~2 WAL/s, or roughly 1-2 TiB of WAL data generated per day). So at some scale, the process might not converge.
Also, we apply changes in the same system, there are 2x writes anyway – though, it happens asynchronously with pg_squeeze, unlike with triggers (though, that "delta" table pg_repack temporarily writes to, it's very light in terms of indexes, and we do only INSERTs, so this amplification is not 2x in terms of IO and timing overhead, right?)