不同类型的自动真空是否有不同的性能特征？

Question

在监视我的数据库中的自动真空活动时，我注意到带有(to prevent wraparound)标记的自真空似乎比“常规”的自吸尘器花费的时间更长。这让我开始尝试理解各种“类型”或自动真空在性能/行为上的差异。

从医生们中，我发现了几个不同的原因，为什么自动真空可能会VACUUM一个表：

1. 该表具有需要冻结的旧事务(relfrozenxid > min(autovacuum_freeze_max_age, table.autovacuum_freeze_max_age)。这是"(to prevent wraparound)“自动真空。
2. 自上一次VACUUM超过“真空阈值”以来，表中淘汰的元组数

还有其他我失踪的地方吗？

对于手动VACUUM，似乎暴露出的“攻击性”旋钮是FREEZE和DISABLE_PAGE_SKIPPING。这些不同类型的自动真空是否曾经使用过这些选项，如果有，什么时候使用？

Answer 1

在监视我的数据库中的自动真空活动时，我注意到带有标记(以防止环绕)的自真空似乎要比“常规”自吸尘器花费更长的时间。

这是意料之中的。他们必须做更多的工作。这些基本上是由自动真空运行的vacuum freeze。

冻结元组意味着用一个特殊的固定值FrozenTransactionId (xid 3)替换它们的事务ID，从而将它们标记为所有当前和未来事务可见。由于元组的xmin存储在磁盘上的元组中，这意味着每个尚未冻结的元组都需要进行修改。这通常会触发一个完整的页面写入，因为元组通常是自上一个检查点以来对页面的第一次修改，导致对每个页面上的第一个冻结元组进行8k的写入。(这也会增加WAL，因此也会导致PITR备份、复制流等)。

在PostgreSQL 9.6及更低版本中的冻结真空不能跳过表的部分；它们必须每次扫描整个表，即使只有一点点是冻结的候选。

除非你调整自动真空，以更积极地冻结，它往往离开强制结冰相当晚，然后做了大量的工作在一次。这是有效的，因为我们不会扫描很多次表，但昂贵，因为我们做了大量的工作，每次我们处理它。

当真空不是冻结元组时，它仍在做许多相同的工作。但是它每次传递的页面数量通常要少得多，因为它只需要关心由自提交事务设置的非锁定专用xmax的元组。具有这些元组的页面也更有可能在缓存中，因为它们最近被删除了，而且它们的任何multixact数据也更有可能在缓存中。

您可以通过以下方式使冷冻真空更快：

• 降低autovacuum_vacuum_cost_delay -这将使自动真空使用更多的资源，给系统增加更多的负载，但运行速度更快。
• 降低autovacuum_freeze_max_age，使他们更频繁地运行，每次做的工作更少。这总体上效率较低，因为每次都必须扫描整个表，在读取表时将页面从OS缓冲区缓存中删除。(Pg使用环缓冲区进行seq扫描，但操作系统一般不会使用)。但是，这意味着我们对每一次传递进行更少的写入，每次传递都需要更少的时间。
• 使用COPY选项执行FREEZE -在TRUNCATEd或CREATEd的事务中大容量加载表。用这种方式装载的元组从预冻开始。(有关详细信息，请参阅COPY手册)。
• 在大量加载表之后，手动冻结表，因此您可以在控制的时间支付冻结成本。

就我个人而言，我希望普通的VACUUMs (和自动真空)做更多的机会冻结；特别是，如果我们刚刚触摸了页面上的项目指针数组，将一些元组标记为空闲空间，那么我们可能应该在页面脏的时候扫描可冻结的元组。这将与PostgreSQL 10中的新冻结映射代码很好地兼容。

在PostgreSQL 9.6中，冷冻有一些很大的改进，它减少了反复使用的吸尘器对桌子的影响，使冷冻更便宜。由于在可见性映射中引入了冻结映射功能，我们可以避免扫描整个表，跳过冻结的页面。请参见提交a892234和fd31cd265。

commit fd31cd265138019dcccc9b5fe53043670898bc9f
Author: Robert Haas <rhaas@postgresql.org>
Date:   Thu Mar 10 16:12:10 2016 -0500

    Don't vacuum all-frozen pages.

    Commit a892234f830e832110f63fc0a2afce2fb21d1584 gave us enough
    infrastructure to avoid vacuuming pages where every tuple on the
    page is already frozen.  So, replace the notion of a scan_all or
    whole-table vacuum with the less onerous notion of an "aggressive"
    vacuum, which will pages that are all-visible, but still skip those
    that are all-frozen.

    This should greatly reduce the cost of anti-wraparound vacuuming
    on large clusters where the majority of data is never touched
    between one cycle and the next, because we'll no longer have to
    read all of those pages only to find out that we don't need to
    do anything with them.

    Patch by me, reviewed by Masahiko Sawada.

我认为PostgreSQL 10的工作也在进行中，以完全避免修改磁盘上的元组以将其标记为冻结，但找不到相关的邮件列表线程atm。