我们正在研究我们的一台虚拟机中的 I/O 负载及其优化可能性，结果表明大部分负载是由 PostgreSQL 的统计收集器生成的。它在 3.5 到 6.5 MB/s 之间跳跃。我已经发现一些有趣的来源在这个话题他们建议使用 tmpfs 将大部分统计数据保存在内存中，这对我来说很有意义，并且具体的虚拟机有足够的可用 RAM 来支持这种情况。
来源 1 内容如下：
重新启动后，PostgreSQL 会将文件复制到新位置（并在停止时复制回来）。
这与temp配置名称相结合stats_temp_directory听起来就像数据保存在其他地方。
那么，如果 Postgres 进程非正常关闭，临时数据会发生什么情况？如果该进程在过去一周内运行没有任何问题，那么临时数据会完全丢失吗？或者 Postgres 是否会在运行时定期将数据保留在临时目录之外？非正常关闭后，它可以在重新启动时简单地使用可用的临时数据吗？
我之所以问这个问题，是因为目前一旦写入的数据就会保留在本地文件系统中，并且写入数据的操作似乎是原子的，但如果我们切换到使用 tmpfs，如果整个服务器由于某种原因瘫痪，几周的统计数据可能会丢失。
有没有办法让 Postgres 定期将数据保存在 tmpfs 之外，比如每小时一次左右？
或者我需要使用一些覆盖/堆叠/任何文件系统，将持久文件系统安装为较低文件系统，将 tmpfs 安装为较高文件系统，并找到某种方式偶尔手动同步？
谢谢！
答案1
PostgreSQL 没有内置工具来定期保存收集器统计信息。它们被认为是可替换的。请记住，有一个分析器收集的表统计信息与统计信息收集器收集的统计信息之间的差异。后者是 stats_temp_directory 中的内容。
因此，您的答案取决于为什么要在发生崩溃时保留它们。有两个原因：
- 您不希望 Autovacuum 因为忘记了表的更新次数而错过它们；
- 您正在使用表更新计数作为某处监控的一部分。
我认为第一个原因可能无关紧要，除非你有什么原因导致 PostgreSQL 每天都意外关闭，在这种情况下你应该修复它。此外，你可以在重新启动 Postgres 后通过运行数据库范围的 VACUUM 来修复问题。
第二个原因，仅仅积累计数器本身并没有多大用处。我的意思是，如果一个表在其生命周期内有 100,000 次删除，这是否意味着它在 100 天内每天有 1000 次删除，还是意味着昨天有人删除了一半的表？你不知道。因此，如果你关心这些计数，你应该每天或每小时对统计数据进行快照，这样你就可以得到时间和计数。你可以看看尝试恢复 pgStatsPack，这个工具就可以实现这个功能。