performance - 使用 pg_stat_statements 收集大型统计集？

Question

根据 Postgres pg_stat_statements文档:

The module requires additional shared memory proportional to pg_stat_statements.max. Note that this memory is consumed whenever the module is loaded, even if pg_stat_statements.track is set to none.

还有:

The representative query texts are kept in an external disk file, and do not consume shared memory. Therefore, even very lengthy query texts can be stored successfully. However, if many long query texts are accumulated, the external file might grow unmanageably large.

从这些中不清楚高 pg_stat_statements.max 的实际内存成本是多少 - 比如 100k 或 500k(默认为 5k)。将水平设置得那么高是否安全，如此高的水平可能会产生负面影响吗？通过 logstash/fluentd 将统计数据聚合到外部数据库中是否会成为超过特定大小的首选方法？

Answer 1

1.

根据我的阅读，它对查询进行哈希处理并将其保存在数据库中，将文本保存到文件系统。因此，下一个问题比共享内存过载更令人期待:

if many long query texts are accumulated, the external file might grow unmanageably large

文本的散列比文本小得多，我认为你不应该担心比较长查询的扩展内存消耗。特别是知道该扩展使用查询分析器(它将适用于EVERY 查询ANYWAY):

the queryid hash value is computed on the post-parse-analysis representation of the queries

设置 pg_stat_statements.max 10 倍大应该占用 10 倍的共享内存我相信。增长应该是线性的。 文档中没有这么说，但逻辑上应该是这样。

将设置设置为不同的值是否安全没有答案，因为没有关于其他配置值和您拥有的硬件的数据。但由于增长应该是线性的，请考虑这个答案:“如果将其设置为 5K，并且查询运行时间几乎没有增长，那么将其设置为 50K 将几乎没有延长十倍”。顺便说一句，我的问题 - 谁会挖掘 50000 条慢语句？ :)

2.

此扩展程序已经对“dis-valued”语句进行了预聚合。您可以直接在数据库上选择它，因此将数据移动到其他数据库并在那里选择它只会给您带来卸载原始数据库并加载另一个数据库的好处。换句话说，您为原始查询节省了 50MB，但在另一个查询上花费了相同的费用。是否有意义？对我来说-是的。这是我自己做的。但我也保存语句的执行计划(这不是 pg_stat_statements 扩展的一部分)。我相信这取决于你拥有什么和你拥有什么。绝对没有必要仅仅因为有很多查询就需要这样做。再次强调，除非你有这么大的文件，扩展可以

As a recovery method if that happens, pg_stat_statements may choose to discard the query texts, whereupon all existing entries in the pg_stat_statements view will show null query fields