下面是在heroku管理的postgresql 9.2数据库中对所有表执行手动真空操作之前和之后膨胀最大的表。如你所见，变化不大，有些浪费甚至增加了。。。原因可能是什么？这是正常的行为吗？
之前：
type | schemaname | object_name | bloat | waste
-------+------------+------------------------+-------+------------
index | public | table_1 | 1.4 | 113 MB
table | public | table_2 | 1.1 | 92 MB
table | public | table_3 | 1.1 | 70 MB
index | public | table_4 | 1.2 | 66 MB
index | public | table_5 | 1.2 | 65 MB
index | public | table_6 | 1.2 | 64 MB
index | public | table_7 | 1.1 | 34 MB
table | public | table_8 | 1.1 | 19 MB
之后：
type | schemaname | object_name | bloat | waste
-------+------------+------------------------+-------+------------
index | public | table_1 | 1.4 | 123 MB
table | public | table_2 | 1.1 | 82 MB
table | public | table_3 | 1.1 | 82 MB
index | public | table_4 | 1.3 | 72 MB
index | public | table_5 | 1.3 | 72 MB
index | public | table_6 | 1.3 | 71 MB
index | public | table_7 | 1.1 | 39 MB
table | public | table_8 | 1.1 | 19 MB
最佳答案
如果您需要将您的桌子打包到最小大小，请运行VACUUM FULL。VACUUM不尝试压缩数据页或释放磁盘空间，除非从表的末尾开始（这是一种廉价的操作）。
通常，简单的VACUUM是更可取的方法。死元组占用的空间可以被以后的更新重用，更新后的行版本可以这样写入同一个数据页。如果将所有内容都打包紧密，则新的行版本总是必须附加到表的末尾。有些松弛通常会提高写性能—除了只读表，它可能是VACUUM FULL（once）甚至CLUSTER的候选表。
客户端程序具有vacuumdb（-f）开关。--full