在PostgreSQL 8.3上备份并在PostgreSQL 9.4中还原后，数据库大小减小了

我pg_dump在托管在PostgreSQL 8.3服务器上的JIRA数据库上进行了操作。之后的数据库大小vacuum full为217132652（大约207 MB）。

然后，我使用以下命令在PostgreSQL 9.4服务器上还原了JIRA数据库：

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

我假设自从使用以来，还原将在发生任何错误时退出ON_ERROR_STOP=1，但是SQL脚本正确完成了（尽管有些警告与数据还原无关）。

我最终得到了一个大小为158019348（大约151 MB）的数据库。

那么，这是什么故事呢？我是否可以仅假设数据库已成功恢复并且PostgreSQL优化了其存储引擎（介于8.3和9.4版本之间），并且正在更有效地利用空间？

当您还原数据库你就可以打包的所有信息，与行（或指数）之间没有空的空间，除非某些特定设置到位（基本上是：FILLFACTOR为表和FILLFACTOR用于索引）。

另一方面，当您的数据库已经使用了一段时间，并且您拥有共享的插入，更新和删除操作时，将显示可用的未使用空间。这是因为PostgreSQL和Multiversion并发控制（又名MVCC）的工作方式。MVCC允许更少的锁定，这基本上意味着您可以节省 时间。但是您要为空间付出代价：

1. 每个UPDATE都等同于INSERT与和DELETE，以及与两者相关联的开销（至少在使用的空间方面）。
2. 当你有几个交易运行，每一个被INSERT荷兰国际集团，UPDATE荷兰国际集团和DELETE荷兰国际集团，你有参与的每一行的同时多个副本。
3. 提交后，分配给这些行版本的空间将不会立即释放，并且有一段时间将成为存储表数据（和索引）的文件中未使用的空间。

Autovacuum会照顾到默认情况下可重用的空间，或者您可以采用一些特定的常规吸尘程序。

这个事实已经可以解释大小的变化。

版本之间也可能进行了优化。并可以解释进一步的改进。还可以针对速度而不是大小进行优化，并且实际大小实际上可以从一个版本扩展到另一个版本。我真的不知道该说些什么。尽管@Erwin的评论指出，自8.3版以来，已经发生了使表缩小的更改和使表膨胀（增长）的更改。

为了区分这两种效果，如果您好奇，可以按照@Jack Douglas的建议在8.3上还原数据库。它很可能会缩小尺寸。如果它缩小到小于151 MB（小于9.4版时的大小），则未使用空间的删除使您的数据库缩小，而版本更改实际上使您的数据库增长。

为了更好地了解MVCC，请查看Bruce Momjian的演讲。