2

我只是在经历一种情况，我根本没有得到我的问题的线索。

我有一张名为名称的表（带有列名称和时间）。该表每分钟插入大量行。这些插入的记录会在特定的时间间隔内被删除。所以，最后我停止插入数据并从表中删除所有行。

我的数据库版本详细信息 

impss=# SELECT  version();
                                           version                                            
----------------------------------------------------------------------------------------------
 PostgreSQL 8.3.7 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2
(1 row)

但是当我发出查询以查找表的大小时，我仍然得到一些大小。

impss=# SELECT  pg_size_pretty( pg_total_relation_size('names')) ;
 pg_size_pretty 
----------------
 1504 kB
(1 row)

第一个问题为什么它仍然显示一些大小，尽管我已经从表中删除了所有记录。

要查找上次 autovacuum 完成的时间，我发出了以下查询：

当前时间是 

impss=# select now(); 
               now                
----------------------------------
 2012-11-08 20:21:10.550434+05:30
(1 row)

impss=# SELECT last_autovacuum  from pg_stat_user_tables where relname='names';
         last_autovacuum          
----------------------------------
 2012-11-08 17:51:31.995618+05:30

第二个问题：为什么在这段时间之后还没有执行 autovacuum 过程，尽管我的数据库不是很忙，而且我已经停止了对该表的所有事务。

所以，请告诉我是否需要做任何特定的配置来进行频繁的清理，以便在记录被删除后我可以取回所有空间。

4

2 回答 2

6

第一个查询 - autovacuum 不会调用 VACUUM FULL - 所以它不会影响关系大小（通常，但是当在执行真空时没有其他访问关系的请求时，它可以从头到尾修剪关系文件） , 第二个查询 - 当 autovacuum_vacuum_threshold 行被修改并且修改的行/所有行高于 autovacuum_vacuum_scale_factor 时执行 autovacuum。这两个值都在 postgresql.conf 中，默认值为 50 行和 20%。

Autovacuum 执行不依赖于当前的数据库负载 - 它只依赖于更新/删除的行数。

于 2012-11-08T18:37:17.007 回答
2

您正在使用 8.3 系列的一个非常旧的版本，它已经过时并且很快就会结束生命。请参阅 postgresql.org/support/versioning。紧急升级到 8.3.21，然后准备升级到更新的主要版本。阅读每个主要版本的发行说明，尤其是“迁移”部分。

在您的情况下，版本是相关的，因为自 8.3 以来 autovacuum 已经改进了很多。例如，8.4 摆脱了对空闲空间地图的手动管理。在 8.3 及更低版本中，您需要保持max_fsm_pages（注意：有意链接到 8.3 文档）足够高，vacuum以便跟踪表中的所有可用空间。如果您超出范围max_fsm_pages，您将开始失去空间并需要进行VACUUM FULL恢复。当然，8.3VACUUM FULL很烂，速度很慢，而且你有时需要在REINDEX之后，所以你最好使用CLUSTER.

VACUUM通常不会移动元组以允许它截断文件，但是在没有可用空间映射问题的较新版本上，错误的max_fsm_pages设置不太可能导致无限的表增长；它会稳定下来。

严重地。升级。

为了缓解，计划一些停机时间。检查日志中的警告max_fsm_pages并在需要时增加它，然后是CLUSTER你的表。准备好这需要一段时间。还要调整 autovacuum 以更积极地运行。

于 2012-11-09T01:37:57.993 回答