# Recuperación de espacio de almacenamiento mediante el vaciado
El control de simultaneidad multiversión (MVCC) de PostgreSQL ayuda a preservar la integridad de los datos al guardar una copia interna de las filas actualizadas o eliminadas hasta que se confirme o anule una transacción. Estas copias, también denominadas *tuplas*, pueden sobrecargar las tablas si no se limpian con regularidad. Las instancias de PostgreSQL ordenan las transacciones por sus ID de transacción. PostgreSQL utiliza el MVCC basado en el ID de transacción para controlar la visibilidad de las tuplas y aislar las transacciones. Cada transacción establece una instantánea de los datos y cada tupla tiene una versión. Tanto la instantánea como la versión se basan en el ID de la transacción.
Para limpiar los datos, la utilidad `VACUUM` realiza cuatro funciones clave en PostgreSQL:
+ `VACUUM`: elimina las versiones de filas caducadas, lo que permite reutilizar el espacio que ocupaban.
+ `VACUUM FULL`: proporciona una desfragmentación completa al eliminar las versiones con filas muertas y compactar las tablas, lo que reduce el tamaño y aumenta la eficiencia.
+ `VACUUM FREEZE`: protege contra los problemas relacionados con los ID de las transacciones al marcar las versiones antiguas de las filas como inmovilizadas.
+ `VACUUM ANALYZE`: elimina las versiones de las filas inactivas y actualiza las estadísticas de planificación de consultas de la base de datos. Es una combinación de las funciones `VACUUM` y `ANALYZE`. Para obtener más información sobre cómo funciona `ANALYZE` en Base de datos ilimitada de Aurora PostgreSQL, consulte [ANALYZE](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.ANALYZE).
De igual modo que con el MVCC, el vaciado en Aurora PostgreSQL se basa en el ID de la transacción. Si hay una transacción en curso cuando se inicia el vaciado, no se eliminan las filas que aún estén visibles de esa transacción.
Para obtener más información acerca de la utilidad `VACUUM`, consulte [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) en la documentación de PostgreSQL. Para obtener más información sobre la compatibilidad con `VACUUM` en Base de datos ilimitada de Aurora PostgreSQL, consulte [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM).
**Topics**
+ [AUTOVACUUM](#limitless-autovacuum)
+ [Vaciado basado en el tiempo en Base de datos ilimitada de Aurora PostgreSQL](#limitless-vacuum.time-based)
+ [Uso de las estadísticas de base de datos para vaciar](#limitless-vacuum.stats)
+ [Diferencias en el comportamiento de vaciado entre Aurora PostgreSQL y Base de datos ilimitada de Aurora PostgreSQL](#limitless-vacuum-limitations)
## AUTOVACUUM
Aurora PostgreSQL utiliza las `VACUUM` y `AUTOVACUUM` para eliminar las tuplas innecesarias. El mecanismo subyacente para `AUTOVACUUM` y el `VACUUM` manual son los mismos; la única diferencia es la automatización.
`AUTOVACUUM` en Aurora PostgreSQL y en Base de datos ilimitada de Aurora PostgreSQL es una combinación de las utilidades `VACUUM` y `ANALYZE`. `AUTOVACUUM` determina qué bases de datos y tablas se van a limpiar, de acuerdo con una regla predefinida, como el porcentaje de tuplas inactivas y el número de inserciones.
Por ejemplo, `AUTOVACUUM` se despierta periódicamente para realizar la limpieza. El intervalo de tiempo lo controla el parámetro `autovacuum_naptime`. El valor predeterminado es 1 minuto. Los valores predeterminados para los parámetros de configuración `AUTOVACUUM` y `VACUUM` son los mismos para Base de datos ilimitada de Aurora PostgreSQL y para Aurora PostgreSQL.
El daemon `AUTOVACUUM`, si está activado, emite comandos `ANALYZE` automáticamente siempre que el contenido de una tabla haya cambiado lo suficiente. En Base de datos ilimitada de Aurora PostgreSQL, `AUTOVACUUM` emite `ANALYZE` tanto en los enrutadores como en las particiones.
Para obtener más información sobre los parámetros de almacenamiento de tablas y el daemon `AUTOVACUUM` asociados a `AUTOVACUUM`, consulte [The autovacuum daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM ) y [Storage parameters](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) en la documentación de PostgreSQL.
## Vaciado basado en el tiempo en Base de datos ilimitada de Aurora PostgreSQL
Base de datos ilimitada de Aurora PostgreSQL es un sistema distribuido, lo que significa que pueden participar varias instancias en una transacción. Por lo tanto, no se aplica la visibilidad basada en el ID de la transacción. En cambio, Base de datos ilimitada de Aurora PostgreSQL emplea la utilidad *basada en el tiempo*, pues los ID de transacción no están unificados en todas las instancias, sino que el tiempo se puede unificar en todas las instancias. Cada instantánea de transacción y cada versión de la tupla obedecen al tiempo en lugar de al ID de la transacción. Para ser más específicos, una instantánea de transacción tiene una hora de inicio de la instantánea y una tupla tiene una hora de creación (cuando ocurre `INSERT` o `UPDATE`) y una hora de eliminación (cuando ocurre `DELETE`).
Para mantener la coherencia de datos en todas las instancias del grupo de particiones de base de datos, Base de datos ilimitada de Aurora PostgreSQL debe asegurarse de que al vaciar no se elimine ninguna tupla que aún esté visible para alguna transacción activa del grupo de particiones de base de datos. Por ello, el vaciado en Base de datos ilimitada de Aurora PostgreSQL también se basa en el tiempo. Otros aspectos de `VACUUM` siguen siendo los mismos, como el hecho de que, para ejecutar `VACUUM` en una tabla en particular, el usuario debe tener acceso a esa tabla.
**nota**
Recomendamos encarecidamente que no deje las transacciones abiertas durante períodos de tiempo prolongados.
El vaciado basado en el tiempo consume más memoria que el vaciado basado en el ID de transacción.
En el siguiente ejemplo, se ilustra cómo funciona el vaciado basado en el tiempo.
1. Una tabla de clientes se distribuye en cuatro particiones.
1. La transacción 1 comienza con una lectura repetible y va dirigida a solo una partición (partición 1). Esta transacción permanece abierta.
La transacción 1 es más antigua que cualquier otra transacción iniciada después de ella.
1. La transacción 2 comienza más tarde, elimina todas las tuplas de una tabla y, a continuación, se confirma.
1. Si `AUTOVACUUM` o `VACUUM` manual intenta limpiar las tuplas inactivas (inactivas debido a la transacción 2), no se elimina nada.
Esto es cierto no solo para la partición 1, sino también para las particiones 2 a 4, ya que es posible que la transacción 1 aún necesite acceder a estas tuplas. Gracias al MVCC, siguen siendo visibles para la transacción 1.
El último paso se realiza mediante la sincronización, de modo que todas las particiones estén al tanto de la transacción 1, aunque la transacción 1 no afecte a todas.
## Uso de las estadísticas de base de datos para vaciar
Para obtener información sobre las tuplas que pueda necesitar para la limpieza, use la vista [limitless\_stat\_all\_tables](limitless-monitoring-views.md#limitless_stat_all_tables), cuyo funcionamiento es similar al de la vista [pg\_stat\_all\_tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW). El siguiente ejemplo consulta la vista.
```
SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';
```
Del mismo modo, use [limitless\_stat\_database](limitless-monitoring-views.md#limitless_stat_database) en lugar de [pg\_stat\_database](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW), y [limitless\_stat\_activity](limitless-monitoring-views.md#limitless_stat_activity) en lugar de [pg\_stat\_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW) para las estadísticas de base de datos.
Para comprobar el uso del disco, utilice la función [limitless\_stat\_relation\_sizes](limitless-monitoring-functions.md#limitless_stat_relation_sizes), que funciona de forma similar a [pg\_relation\_size](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-DBOBJECT). El siguiente ejemplo consulta la función.
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');
```
Para hacer el seguimiento del progreso de una operación `VACUUM` en Base de datos ilimitada de Aurora PostgreSQL, use la vista [limitless\_stat\_progress\_vacuum](limitless-monitoring-views.md#limitless_stat_progress_vacuum) en lugar de [pg\_stat\_progress\_vacuum](https://www.postgresql.org/docs/15/progress-reporting.html#VACUUM-PROGRESS-REPORTING). El siguiente ejemplo consulta la vista.
```
SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
```
Para obtener más información, consulte [Vistas de Base de datos ilimitada de Aurora PostgreSQL](limitless-monitoring-views.md) y [Funciones de Base de datos ilimitada de Aurora PostgreSQL](limitless-monitoring-functions.md).
## Diferencias en el comportamiento de vaciado entre Aurora PostgreSQL y Base de datos ilimitada de Aurora PostgreSQL
A continuación se enumeran otras diferencias entre Aurora PostgreSQL y Base de datos ilimitada de Aurora PostgreSQL en cuanto al funcionamiento del vaciado:
+ Aurora PostgreSQL realiza operaciones de `VACUUM` con los ID de transacción hasta la transacción en curso más antigua. Si no hay ninguna transacción en curso en la base de datos, `VACUUM` realiza la operación hasta la última transacción.
+ Base de datos ilimitada de Aurora PostgreSQL sincroniza la instantánea de tiempo más antigua cada diez segundos. Por lo tanto, es posible que `VACUUM` no realice la operación en ninguna transacción que se haya ejecutado en los últimos diez segundos.
Para obtener más información sobre la compatibilidad de `VACUUM` en Base de datos ilimitada de Aurora PostgreSQL, consulte [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM) en la [Referencia sobre Base de datos ilimitada de Aurora PostgreSQLReferencia sobre Base de datos ilimitada](limitless-reference.md).