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

#1 楼

VACUUM仅在非临时表中的更新或删除的行上才需要。显然，您正在执行许多INSERT操作，但是从说明中并不能看出您也在执行大量UPDATE或DELETE操作。列。此外，更重要的是，还有一个pg_stat_all_tables列，该列告诉每个表需要清理多少行。 />
您可能的策略是取消预定的VACUUM，关注此视图并检查n_tup_upd显着上升的表。然后，仅将主动式VACUUM应用于这些表。如果有一些大型表的行永远不会被删除或更新，并且只有在较小的表上才需要使用激进的VACUUM，这将是一个成功。 。

#2 楼

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

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

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


更新语句中的冗余数据

还请注意，临时表需要手动VACUUM和ANALYZE。我在CREATE TABLE上引用了手册：


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

#3 楼

尽管我同意使用自动功能最好，而不是在数据库范围内运行，但在大多数情况下，需要对每个表进行调整。和分析，我已经看到了几个实例，在这些实例中，执行大量插入/更新但删除很少的数据库永远不会完成分析并开始表现不佳。

解决方案是进入被使用的表大量查询，并对其进行自动查询设置，然后将这些表的自动分析设置设置为每天或每隔一天进行分析的位置。

您可以在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;