我目前正在清理一个包含 2 个索引和 2.5 亿个事件行以及大约同样多的死行(或更多)的表。我从我的客户端计算机(笔记本电脑)向我的服务器发出了命令 VACCUM FULL ANALYZE。过去 3-4 天左右，它一直在开展业务；我想知道它是否会很快结束，因为我有很多工作要做!
该服务器有一个四码 Xeon 2.66 GHz 处理器、12 GB 或 RAM 和一个 RAID Controller ，该 Controller 连接到 RAID 1 配置中的 2 x 10K rpm 146 GB SAS HD；它正在运行 Suse Linux。我想知道...
现在，首先 VACUUM postmaster 进程似乎只使用一个核心。其次，我没有看到非常高的 I/O 写入与 I/O 空闲时间比率。第三，通过调用 procinfo ，我可以推断 VACUUM 进程花费大部分时间 (88%) 等待 I/0。
那么为什么不通过线程使用更多内核来使 RAID Controller 过载(获得高 I/O 写入空闲率)？如果 I/O 负载不高，为什么要等待 I/O？为什么所有这些权力/资源都唾手可得？在我看来 VACUUM 可以而且应该是多线程的，尤其是当它在一个巨大的表上工作并且它是唯一一个工作时!
另外，他们是否可以配置 postgresql.conf 以使其多线程处理此类 VACUUM？我可以杀死它并仍然受益于它的部分清理吗？我需要在那张 table 上工作。
[我使用的是 PostgreSQL 8.1]
再次感谢
最佳答案
您没有说明您使用的是什么版本的 PostgreSQL。有可能是 8.0 之前的吗？
我有这个完全相同的场景。你最好的:
如果您使用的是 8.x，请查看 autovacuum 选项。真空是单线程的，没有什么可以使它使用多线程。
关于PostgreSQL 长 VACUUM，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/433737/