在9.1下是否仍建议使用常规VACUUM ANALYZE？

我在Ubuntu上使用PostgreSQL 9.1。是否VACUUM ANALYZE仍建议使用预定时间，还是自动真空足以满足所有需求？

如果答案是“取决于”，则：

• 我的数据库比较大（压缩的转储大小为30 GiB，数据目录为200 GiB）
• 我将ETL输入数据库，每周导入近300万行
• 更改最频繁的表都从主表继承，主表中没有数据（数据按周划分）
• 我创建每小时汇总，并从那里创建每日，每周和每月报告

我要问的是因为计划安排VACUUM ANALYZE正在影响我的报告。它运行了5个多小时，本周我不得不杀死它两次，因为它影响了常规数据库的导入。check_postgres不会报告数据库有任何重大膨胀，所以这并不是真正的问题。

从文档中，autovacuum还应注意事务ID的回绕。问题是：我还需要一个VACUUM ANALYZE吗？

VACUUM仅在非临时表中的更新或删除的行上才需要。显然，您正在执行许多INSERT，但是从描述中并不能看出您也在执行许多UPDATE或DELETE。

可以使用pg_stat_all_tables视图（尤其是n_tup_upd和n_tup_del列）跟踪这些操作。而且，更重要的是n_dead_tup，每一列都有一列告诉需要清理的行数。（有关与统计信息收集相关的功能和视图，请参阅文档中的监视统计信息）。

在您的情况下，一种可能的策略是取消预定的VACUUM，密切关注此视图并检查哪些表n_dead_tup显着上升。然后仅将主动式VACUUM应用于这些表。如果有大型表的行永远不会被删除或更新，并且只有在较小的表上才需要使用主动VACUUM，这将是一个胜利。

但是请继续运行ANALYZE，以使优化器始终具有最新统计信息。

在您的问题中，我看不到任何无法解决的问题autovacuum。这在很大程度上取决于您的写作活动方式。您提到每周有300万新行，但是INSERT（或COPY）通常不会造成表和索引膨胀。（autovacuum只需要处理列统计信息，可见性图和一些次要工作即可）。UPDATE并且DELETE是导致表和索引膨胀的主要原因，尤其是在针对随机行的情况下。我在您的问题中没有看到任何那个。

autovacuum已经走了很长一段路，并且在Postgres 9.1或更高版本中做得很好。我来看看autovacuum设置。如果吸尘会干扰您的工作负荷，请查看“基于成本的真空延迟”。手动吸尘应该是罕见的例外。

如果您有很多随机数UPDATE，则可能需要将设置为FILLFACTOR小于100的值，以便立即进行HOT更新并减少对的需求VACUUM。有关HOT更新的更多信息：

• 更新语句中的冗余数据

另请注意，临时表需要手动VACUUM＆ANALYZE。我引用以下手册CREATE TABLE：

该自动清理守护程序不能访问，因此不能真空或分析临时表。因此，应通过会话SQL命令执行适当的清理和分析操作。例如，如果要在复杂查询中使用ANALYZE临时表，则在填充后在临时表上运行是明智的。

虽然我同意使用自动功能最好，而不是在数据库范围内运行，但在大多数情况下，必须对每个表进行调整。

我不太同意postgres将真空与分析结合在一起的设计选择，我已经看到几个实例，其中执行大量插入/更新但很少删除的数据库永远不会完成分析并开始表现不佳。

解决方案是进入使用频繁且受到大量查询的表，并将这些表的自动分析设置设置为某个或每隔一天进行一次分析的位置。

您可以在自动真空选项卡上的gui中找到每表的设置，然后将在其中看到分析设置，您可以独立于真空进行设置。

设置最终出现在reloptions表中，可以在查询中看到

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

并进行积极分析的样本值可能是

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

查看上次表何时自动分析查询

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;