pg_squeeze is an open source PostgreSQL extension that enables automatic and transparent fixing of bloated tables – without extensive table locking. The process fully works in the background.
KEY BENEFITS
- More aggressive space reduction
- Close-to lock-free table reorganization
- Ability to move tables between tablespaces (without downtime)
- Ability to cluster tables (without downtime)
- Builtin advanced scheduling
- Fully Open Source
pg_squeeze is not a replacement for autovacuum – it is an add-on to perform cleanups even better.
PostgreSQL utiliza un mecanismo llamado «MVCC» (Multi Version Concurrency Control) para almacenar datos. Como lo sugiere el nombre, MVCC tendrá varias versiones de una fila para soportar la mayor concurrencia posible. En algún punto, estas rows adicionales deben ser removidas del almacenamiento y es allí donde VACUUM entra en juego
A diferencia de los comandos built-in «VACUUM FULL» o «CLUSTER«, con «pg_squeeze» no hay períodos extendidos de bloqueo total de tablas y por ello las lecturas y escrituras no están bloqueadas durante el rebuild. Esto es posible por un enfoque innovador utilizando archivos de log y logical decoding (en vez de triggers) para capturar posibles cambios de datos a la tabla que está siendo rearmada. Esto permite, en primer lugar, ahorrar espacio en disco y costo de IO pero, más importante, da la posibilidad de tener tiempos de locks muy cortos, lo que lo hace perfecto para sistemas OLTP críticos
¿Cómo funciona la pg_squeeze compresión de tablas?
La extensión se implementa como un proceso en segundo plano (un framework introducido en la versión 9.4) que monitorea periódicamente tablas definidas por los usuarios. Cuando detecta que una tabla excedió el «umbral de inflado», hace el rebuild automáticamente, el cual sucede concurrentemente en segundo plano con un overhead mínimo de almacenamiento y procesamiento gracias al uso de los slots de replicación junto con logical decoding. Ello permite capturar las modificaciones que se llevan a cabo durante el rebuild. El umbral de «umbral de inflado» es configurable y su ratio se calcula en función del Free Space Map o, en ciertas condiciones, también con la extensión «pgstattuple» si está disponible.
Licencia
- PostgreSQL
FAQ
P: ¿Es seguro? ¿Qué pasa si me quedo sin electricidad durante un rebuild?
R: Sí, es seguro porque el rebuild sucede en una transacción. Es más, se puede configurar un tiempo máximo de bloqueo para que la extensión limite el tiempo para hacer el cambio de tablas.
P: ¿En qué difiere de «pg_repack»?
R: Es diferente en el hecho de que es más amigable ya que no utiliza triggers, automáticamente determina tablas infladas y no requiere el uso de herramientas adicionales
Q: ¿Qué requisitos debe cumplir una tabla para ingresar en rebuild?
R: Más allá de alcanzar el «umbral de inflado», el único requerimiento es que la tabla tenga una clave de identidad, ya sea via un primary key o un unique constraint