PostgreSQL uses a mechanism called “MVCC” (Multi Version Concurrency Control) to store data. As the name already suggests, MVCC will hold various versions of a row to support as much concurrency as possible. At some point, those additional rows must be removed from the storage system and this is where VACUUM comes along.
Unlike with built-in commands “VACUUM FULL” or “CLUSTER”, with “pg_squeeze” there are no extended periods of full-table locking, and consequently reads and writes are not blocked during the rebuild! Also the rebuilding process is very efficient due to a novel approach of using transaction log files and logical decoding (instead of triggers) to capture possible data changes to the table being rebuilt. First of all, this helps save disk space and IO throughput, but even more importantly, it enables very short locking times, making it a perfect fit for mission-critical OLTP systems.
How does pg_squeeze work?
The extension is implemented as a background-worker process (a framework introduced in version 9.4) that periodically monitors user-defined tables. When it detects that a table has exceeded the “bloat threshold”, it kicks in and rebuilds that table automatically! Rebuilding happens concurrently in the background with minimal storage and computational overhead due to the use of Postgres’ built-in replication slots together with logical decoding to extract possible table changes happening during the rebuild from XLOG. Bloat threshold is of course configurable and the bloat ratio calculation is based on the Free Space Map (taking FILLFACTOR also into account) or under certain conditions on the “pgstattuple” extension when it’s available. Additionally, many customization parameters like “minimum table size” can be set with non-suitable tables being ignored. Moreover, reordering using an index or moving the table or indexes to a new tablespace are possible.
- no extensive table locking
- automatic shrinking
- process works in the background
- available as an extension
pg_squeeze can be downloaded from github.com.github.com
- PostgreSQL Licence
Q: Is it safe? What happens when power fails during a table rebuild?
A: Yes, it’s safe because rebuild happens in a transaction. Furthermore, maximum lock time can also be set so that the extension can limit the time taken to switch the table.
Q: How does it differ from “pg_repack”?
A: It is different in the sense that it is more resource-friendly by not using triggers, it automatically determines bloated tables by itself and does not require the use of a separate command line tool.
Q: What are the requirements for tables to be rebuilt?
A: Besides hitting the “bloat threshold”, the only hard-coded requirement is that a table needs to have an identity key, thus defining the primary key or a unique constraint.