Postgresql 显式 VACUUM 与自动 VACUUM：差异？建议？答案

【问题标题】：Postgresql explicit VACUUM vs. auto-VACUUM: Differences? Recommendations?Postgresql 显式 VACUUM 与自动 VACUUM：差异？建议？
【发布时间】：2018-01-08 15:33:49
【问题描述】：

来自 PostgreSQL（相对）新手的快速问题：

我们运行一个批处理，作为其最后一步，删除大部分以前的批处理。

磁盘空间是一个问题，因此我们需要确保 PostgreSQL 自行清理。

除了强制 PostgreSQL 更快地进行垃圾收集之外，在批处理结束时显式调用 VACUUM 与让 auto-VACUUM 守护进程处理它之间有什么区别吗？有什么理由推荐一种方法而不是另一种方法吗？

谢谢！

【问题讨论】：

手动 VACUUM 在 I/O 上会比 autovacuum 更难一些，因为后者旨在最大限度地减少对服务器的影响。请注意，VACUUM/autovacuum 不会回收空间，它们只是将插槽标记为可以重用。如果您确实需要回收空间，您可能需要调查 CLUSTER 或 VACUUM FULL 等。
另外：也许您可以将最终结果写入新表并删除旧表，而不是删除大部分表。这可能会更快，并且会自动回收空间。

标签： postgresql vacuum autovacuum

【解决方案1】：

早在有一个真空吸尘器的时候，它就充满了堵塞。然后 PostgreSQL 家伙添加了非阻塞真空。但你还是得自己安排。

然后，某个天才制作了一个守护程序，当桌子需要它时，它会自动为您运行真空。它使用与您或我将使用的完全相同的真空命令，但有很多设置，尤其是默认设置，使其运行速度更慢且干扰更少。这些设置主要用于工作线程（默认 3）、延迟成本（autovac 为 20 毫秒，常规 vac 为 0 毫秒）和 autovacuum 成本延迟限制（-1，即使用系统设置为 200）。

因此，定期清理非常积极，不会造成任何成本延迟，并且会在您的 IO 子系统允许的情况下尽可能快地运行。它基本上与您的常规工作负载竞争 IO 带宽。

通常，您可以根据自己的情况做以下两件事之一：

一：使 autovacuum 更具侵略性。通过将 autovacuum_vacuum_cost_delay 从 20 降低到 2 到 5 范围内的某个值，它会运行得更快，但仍然不会妨碍太多。

二：手动运行常规吸尘器。由于常规清理默认情况下没有 cost_delay，因此这将是最快的，但也是最具破坏性的。

您的决定取决于使用模式等。

【讨论】：