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 pg_squeeze?

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.

Ventajas

  • No hay bloqueos de tablas extensos
  • Reducción automática de las tablas
  • El proceso corre en segundo plano
  • Disponible como extensión

 

Descarga de pg_squeeze

pg_squeeze está disponible en github.com.

github.com

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ñaticamente 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

¿Quiere saber más de pg_squeeze?

Contáctenos