问题标签 [vacuum]

由于 Postgres 只能在表的末尾添加列，我最终通过在表的末尾添加新列，将它们设置为等于现有列，然后删除原始列来重新排序。

那么，PostgreSQL 对被删除的列释放的内存做了什么？它会自动重用内存，因此单个记录消耗的空间量与以前相同吗？但这需要重写整个表，所以为了避免这种情况，它是否只是在每条记录中保留一堆空白？

好吧，这个问题几乎总结了它。我的数据库活动非常需要更新，我想以编程方式发出真空分析。但是，我收到一条错误消息，指出无法在事务中执行查询。还有其他方法吗？

我有一个非常简单的更新语句：

表 W 只有 90 行，但每行的 losttime 和 state 列大约每 10 秒更新一次。有关于状态和丢失时间的索引（以及主索引）。

我注意到大型数据库（即其他表有很多条目，而不是表 W）在一段时间内，查询变得越来越慢。运行48小时后，我在PqAdminIII的查询窗口中运行计时，执行时间为17分钟！

我对另一个显示相同问题的表有类似的查询：

H 没有任何索引，但我尝试在 H(release) 上放置和删除索引，而行为没有变化。在数据库运行 48 小时并且表 H 有大约 100k 行之后，此查询需要 27 分钟。在查询期间，Postgres 服务器将有一个完全固定的线程（100% CPU 利用率），因此看起来没有任何网络、磁盘等争用。

所以总的来说，我看到的行为是我的数据库按预期运行了大约 5 分钟，然后随着基本维护相关的 UPDATE 命令开始花费越来越长的时间来运行，一切都逐渐停止。到第二天，需要一个小时来完成一个简单的维护周期（一些更新），一开始运行大约 100 毫秒。我似乎很清楚，性能下降与数据库中的信息量呈超线性关系——可能是 N^2 或类似的。

Autovacuum 使用默认设置。我（再次）通读了手册，并没有看到任何让我兴奋的东西。

我在这里挠头。我没有看到任何与 9.0.1 和 9.0.2 发行说明相关的错误修复。谁能帮我理解发生了什么？谢谢，米

-xxxx-

好的，所以我在这里可能有两个问题。

第一次更新现在似乎运行得很快。不知道发生了什么，所以我会假设我需要更频繁地运行 VACUUM / ANALYZE 或某种组合 - 说每分钟左右。我真的很想知道为什么 autovacuum 不为我这样做。

第二次更新继续缓慢运行。查询计划表明索引没有得到有效使用，并且发生了 80k*30k 的交叉，这可能是我观察到的超线性运行时的原因。（大家同意这个计划的解释吗？）

我可以将 UPDATE 转换为 SELECT：

具有相似的运行时间（27 分钟）。

如果我不信任 postgres 优化器并这样做：

然后查询在 ~500 毫秒内运行。

我如何将这些知识转换回以可接受的速度运行的更新？我的尝试：

运行大约 140 秒，速度更快，但仍然非常非常慢。

我可以从这里去哪里？

-xxxx-

VACUUM ANALYZE 已被添加为“例行维护”的一部分，应用程序将大约每分钟左右运行一次，独立于正在运行的任何 autovacuum。

此外，重写了第二个查询以消除已知缓慢的 NOT IN 子句，将其替换为“Left Anti-Semi Join”（嗯？）

我有一个 9.0.1 数据库，其中有两个损坏的表（一个表有 20 行，另一个有 140 行）。这些表对于读取/选择操作似乎很好，但更新表中的某些行会产生错误消息：

错误：无法读取文件“base/16384/16485”中的块 2：仅读取 8192 个字节中的 0 个

2011-04-14 00:15:15 UTC 错误：无法读取文件“base/16384/16543”中的块 3：只读 8192 个字节中的 0 个
2011-04-14 00:15:15 UTC 声明：更新 media_status 集updated_at = now() 在时区“UTC”；

检查文件系统（linux）中损坏的文件，它们不是零字节：ll base/16384/16485 -rwx------ 1 postgres postgres 16384 2011-04-07 09:43 base/16384/16485

我运行了“vacuum(FULL, VERBOSE)”命令，损坏（或至少更新时的错误）消失了。是否期望“vacuum（FULL）”命令会/可以修复表损坏？这是否为可能发生的事情提供了任何线索？

有没有办法确定这种腐败是如何/何时发生的？

我怀疑它可能发生在文件系统级备份期间（即 pg_start_backup()、tar -czf...、pg_stop_backup()），因为我执行了备份并将数据库移动到不同的系统。恢复文件并启动 postgres 后，我开始收到这些错误。我曾尝试使用相同的 tar 存档多次还原，结果相同（在不同的系统上）。

谢谢，丹

我想知道自动吸尘还是手动吸尘哪个好。现在，我们在 cron 作业中手动跟踪，但有时它会在特定表上出现真空。所以我们正在考虑自动吸尘器。它会给生产服务器带来良好的性能吗？请建议。非常感谢。

我在驱动空间有限的嵌入式系统上使用 PostgreSQL。现在 DB 驱动器已满。当我删除数据时，它似乎没有释放任何空间。我试图 VACUUM FULL，但这需要空间。删除最后剩余的索引也是如此。

关于如何在不随机删除内容的情况下释放空间的任何想法？我可以承受丢失一些数据的后果，但我似乎无法真正做到这一点，因为没有足够的空间来 VACUUM FULL。

在 pgAdmin 中，每当表的统计信息过期时，它都会提示：

建议运行 VACUUM

表 schema.table 上的估计行数与实际行数有很大偏差。您应该在此表上运行 VACUUM ANALYZE。

我已经使用 pgAdmin 3 和 Postgres 8.4.4 对它进行了测试，autovacuum=off。每当我单击已更改的表时，提示会立即显示。

假设我正在用 Java 制作一个基于 Web 的系统，我如何检测一个表是否已过期，以便我可以显示类似于 pgAdmin 中的提示？

由于我的应用程序的性质，这里有一些我必须遵循的规则：

1. 我想知道 pg_stats 和 pg_statistic 中某个表的统计信息是否是最新的。

2. 我无法在 postgresql.conf 中设置 autovacuum 标志。（换句话说，autovacuum 标志可以打开或关闭。我无法控制它。我需要判断统计信息是否是最新的，无论 autovacuum 标志是打开还是关闭。）

3. 我不能每次都运行真空/分析以使其保持最新。

4. 当用户选择一个表时，当该表有任何更新（例如删除、插入和更新）未反映在 pg_stats 和 pg_statistic 中时，我需要显示该表已过时的提示。

通过分析 pg_catalog.pg_stat_all_tables 中的时间戳似乎是不可行的。当然，如果一个表之前没有被分析过，我可以在 last_analyze 中检查它是否有时间戳，以确定该表是否是最新的。但是，使用这种方法，当已经有时间戳时，我无法检测表是否是最新的。换句话说，无论我向表中添加多少行，它在 pg_stat_all_tables 中的 last_analyze 时间戳总是用于第一次分析（假设 autovacuum 标志关闭）。因此，我只能在第一次显示“运行 VACUUM 推荐”提示。

通过将 last_analyze 时间戳与当前时间戳进行比较也是不可行的。几天内该表可能没有任何更新。一小时内可能会有大量更新。

鉴于这种情况，我如何始终判断表的统计信息是否是最新的？

我有一个 Postgres 9.0 数据库，我经常对它进行数据转储。

这个数据库有很多索引，每次我恢复转储时，postgres 都会启动后台任务真空吸尘器（对吗？）。该任务消耗大量处理时间和内存来重新创建已恢复转储的索引。

我的问题是：

1. 有没有办法转储数据库数据和该数据库的索引？
2. 如果有办法，是否值得付出努力（我的意思是用索引转储数据会比吸尘器更好）？
3. Oracle 有一些“数据泵”命令可以更快地进行 imp 和 exp。postgres 有类似的东西吗？

提前致谢， 安德烈

I'm using GHood to watch the execution of this implementation of the partition function and expected to see a binary tree. Instead I get this tree:

I've also unsuccessfully tried using lazy natural numbers from Data.Number.Natural as per a suggestion on irc.

When using Vacuum.Cairo I get even less back, just the result of the function run to completion.

我有一个使用以下方法的数据库：

插入方法是这样的：

testCount() 方法是这样的：

获取方法是这样的：

当我运行它时，我得到一个错误：

这是我的 LogCat：

一如既往地感谢您的帮助。