根据 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/fluidd 将统计信息聚合到外部数据库中是否是超过特定大小的首选方法？
最佳答案
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 将几乎没有增长十倍”。顺便说一句，我的问题 - 谁是 gon 来挖掘 50000 个慢语句？ :)
2.
此扩展已经对“贬值”语句进行了预聚合。您可以直接在数据库上选择它，因此将数据移动到其他数据库并在那里选择它只会给您带来卸载原始数据库并加载另一个数据库的好处。换句话说，您可以为原始查询节省 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
关于performance - 使用 pg_stat_statements 收集大型统计集？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34573075/