3 ms·
Are you aware of pg_repack [1]? I haven't had a chance to use it myself yet, but it's designed for reclaiming bloated space without downtime. [1] https://githu
by felixge 9y ago
Are you aware of pg_repack [1]? I haven't had a chance to use it myself yet, but it's designed for reclaiming bloated space without downtime.
[1] https://github.com/reorg/pg_repack/ https://github.com/reorg/pg_repack/
- danmaz74 9y agoWe use pg_repack with automated schedules and it's really helpful.
- jacobkg 9y agoWe tested pg_repack early on. Our experience (at least 5 years ago) was it didn't reliably clean up after itself in all cases so we were left with random triggers in the database. With thousands of customer databases this was a huge potential hassle. I have heard plenty of people use pg_repack so maybe it got better or we didn't test it enough.
- al_james 9y agoWe use pg_repack and hit that exact problem (left over triggers etc). In the end we resorted to creating and dropping the pg_repack extension after each run. (edit: Missed an "and")
- kawsper 9y agoDo you have any idea why their docs are not mentioning this, or even why their software aren't doing that itself?
- cookiecaper 9y agoI haven't used pg_repack in production, but on my development box with PgSQL 10.x, if you end the process early, pg_repack will complain on the next run and ask you to clean up by dropping and re-adding the extension. Maybe this occurs in the wild if the cleanup code is not reached, for whatever reason.