Couple of years ago, I started compiling blog post on pg_reorg but that post never made it to published post because of my procrastination !! Though, I wasn’t disappointed because I got opportunity to talk about removing bloat from tables on databases at one of the PostgreSQL conference. Moreover, Depesz , colleague at OmniTI, wrote a detailed post on how pg_reorg actually works 🙂 So, you must be thinking , What’s up with this blog post ?
Let’s come to the point 🙂
Last month, I received email in pg_reorg mailing list that first release of pg_repack beta1 was released ! So, What is pg_repack ? The first release of pg_repack is simply a fork of pg_reorg. The author provided the reason of the fork is to revive the development of pg_reorg, which has been stagnated since the release of pg_reorg 1.1.7 in August 2011. That makes sense to me. The first release doesn’t’ provide any new functionality but add specifically the missing features planned for pg_reorg 1.1.8 and fixes it’s known bugs. That’s good thing ! As I mentioned, it’s provide same functionality as pg_reorg but now you should follow more lively code of pg_repack instead of pg_reog on PGXN project page 🙂
At OmniTI, the engineers contribute new tools to community and use existing tools. We decided to give a swing at pg_repack because we have been using pg_reorg for last couple of years successfully on production systems and familiar with the code base. Now, pg_repack supports extension so it was pretty easy to install tool as extension on one of the PostgreSQL database system and ran it during low peak hours. The pg_repack run helped to trim down database size from 550GB to 400GB. Now a days,if no graph, it never happened 🙂 Here is the DB size graph for the reference. If you are curious, the graph was created using Circonus monitoring suite.
Thanks to pg_repack authors and contributors. If you haven’t join pg_reorg/pg_repack mailing lists, I would recommend you to join. Keep contributing and sharing the results to community!!