Question

以下是在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

Answer 1

如果您需要将表格打包到最小尺寸，请运行VACUUM FULL。 VACUUM不会尝试压缩数据页或释放磁盘空间，除了从表的末尾（这是一个便宜的操作）。

通常，普通VACUUM是更可取的方法。死元组占用的空间可以在以后的更新中重用，更新的行版本可以通过这种方式写入同一数据页。如果紧紧包装所有内容，则必须将新行版本附加到表的末尾。一些松弛通常提高写入性能 - 除只读表外，它们可能是VACUUM FULL（一次）或CLUSTER的候选者。< / p>

客户端计划vacuumdb具有-f（--full）切换。

Much more information in the Postgres Wiki on vacuuming.

Answer 2

Tl;博士版：看起来并不奇怪。

当行被更新或删除时，mvcc将旧行标记为从txid开始死亡;从该txid开始插入一个新的插入和更新。

自动真空吸尘然后开始，并且正常的DB操作正常。

真空强制自动真空通常会定期和局部地进行。例如，在重大更新或删除后运行它。

真空吸尘器的作用基本上是修剪磁盘页面中的死行。并且，除非我错了，否则通过拆分太满的磁盘页面（与表的填充因子相距太远）为未来的新行创建一些新空间，或者通过合并太空的磁盘页来删除不必要的空间（对于同样的原因）。

postgres vacuum并没有改变膨胀

2 个答案: