Tamaño de la base de datos reducido después de la copia de seguridad en PostgreSQL 8.3 y restauración en PostgreSQL 9.4

Hice un pg_dumpen una base de datos JIRA que estaba alojando en un servidor PostgreSQL 8.3. El tamaño de la base de datos después vacuum fullfue 217132652(aproximadamente 207 MB).

Luego restauré esa base de datos JIRA en un servidor PostgreSQL 9.4 con el siguiente comando:

$ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql

Supongo que la restauración se cerraría con cualquier error desde que lo usé ON_ERROR_STOP=1, pero el script SQL terminó correctamente (a pesar de algunas advertencias no relacionadas con la restauración de datos).

Terminé con una base de datos con un tamaño de 158019348(aproximadamente 151 MB).

Entonces, ¿cuál es la historia aquí? ¿Puedo suponer que la base de datos se restauró con éxito y PostgreSQL optimizó su motor de almacenamiento (en algún lugar entre las versiones 8.3 y 9.4) y está usando el espacio de manera más eficiente?

Cuando restaura una base de datos, tiene toda la información en ella empaquetada , sin espacio vacío entre filas (o en índices), a menos que existan algunas configuraciones específicas (básicamente: FILLFACTORpara tablas e FILLFACTORíndices ).

Por otro lado, cuando su base de datos haya estado en uso durante algún tiempo y haya tenido su parte de inserciones, actualizaciones y eliminaciones, aparecerá el espacio libre no utilizado . Esto se debe a la forma en que funcionan PostgreSQL y el Control de concurrencia multiversional, también conocido como MVCC . MVCC permite menos bloqueos, lo que básicamente significa que ahorra tiempo . Pero pagas un precio en términos de espacio :

1. Cada UPDATEes equivalente a un INSERTjunto con a DELETE, con la sobrecarga (al menos en términos de espacio utilizado) asociada a ambos.
2. Cuando se tiene varias operaciones en ejecución, y cada uno se INSERTing, UPDATEing o DELETEing, que tienen simultáneamente varias copias de cada fila en cuestión.
3. El espacio asignado a estas versiones de fila no se liberará inmediatamente después de la confirmación y, por un tiempo, será espacio no utilizado dentro de los archivos donde se almacenan los datos (e índices) de la tabla.

Autovacuum se encarga de que este espacio se vuelva reutilizable por defecto, o podría tener algún procedimiento específico para la aspiración de rutina .

Este hecho ya puede explicar el cambio de tamaño.

Las optimizaciones entre versiones probablemente también tuvieron lugar; y puede explicar más mejoras. También se podrían haber hecho optimizaciones para la velocidad y no para el tamaño, y el tamaño real podría crecer de una versión a otra. Realmente no sé los detalles para poder contar; aunque el comentario de @Erwin afirma que tanto los cambios que hacen que sus tablas se reduzcan como los cambios que hacen que sus tablas se hinchen (crezcan) se han producido desde la versión 8.3.

Para distinguir entre los dos efectos, si tiene curiosidad, podría simplemente, como sugiere @Jack Douglas, restaurar su base de datos en 8.3. Lo más probable es que disminuya de tamaño. Si se reduce a menos de 151 MB (un tamaño más pequeño que el que obtienes con la versión 9.4), entonces la eliminación del espacio no utilizado hizo que tu DB se redujera, y el cambio de versión realmente hizo que tu DB creciera.

Para una mejor comprensión de MVCC, mire la presentación de Bruce Momjian .