pg_restore 后数据库大小不同（389 GB 与 229 GB）

Question

我使用以下命令在 PostgreSQL 11.6（带有 TimescaleDB 1.60 扩展）中创建了数据库的备份pg_dump：

PGPASSWORD=mypassword pg_dump -h 127.22.0.4 -p 5432 -U postgres -Z0 -Fc database_development

并将其恢复到运行相同版本的 PostgreSQL 11.6（带有 TimescaleDB 1.60 扩展）的新服务器pg_restore。对于恢复，以psql用户身份执行以下命令postgres：

CREATE DATABASE database_development;
\c database_development
CREATE EXTENSION timescaledb;
SELECT timescaledb_pre_restore();

\! time pg_restore -Fc -d database_development /var/lib/postgresql/backups/database_development_2020-02-29

SELECT timescaledb_post_restore();

原始数据库的数据库大小为 389 GB，但恢复的数据库为 229 GB。这些尺寸是通过运行获得的

select pg_size_pretty(pg_database_size('database_development'))

一些差异：

旧数据库存储在 ext4 分区上，而新数据库存储在禁用压缩的 ZFS 文件系统上。两个数据库实例都在具有 Ubuntu 18.04 主机的 Docker 容器内运行。

问题：我们如何解释数据库大小的差异？pg_dump和期间都没有遇到错误pg_restore。

Answer 1

转储不\xe2\x80\x99t 考虑死元组，只考虑活元组，但死元组确实考虑空间，因此存在空间差异。

\n\n

原因是转储是一种逻辑转储，它只会创建语句来插入数据，而死行无论如何都是不可见的。如果您发生大量更新和删除，或者换句话说您的数据库具有高度事务性，它将创建更多死行版本，并且还需要积极的真空来处理膨胀。如果您比较死行与活行计数，在恢复之前和之后您将看到差异。

\n\n

另外，为了更安全，请在转储恢复后对数据库执行手动真空分析，我过去曾看到，由于错误的估计，规划器更改了用于查询的最佳计划。

\n