使用 pg_stat_statements 收集大型统计集？

Question

根据 Postgres pg_stat_statements 文档：

模块需要额外的共享内存，与 pg_stat_statements.max。请注意，每当 模块已加载，即使 pg_stat_statements.track 设置为 none。

还有：

代表性查询文本保存在外部磁盘文件中，并且 不消耗共享内存。因此，即使是非常冗长的查询文本 可以保存成功。但是，如果有很多长查询文本 累积起来，外部文件可能会变得难以管理。

从这些中不清楚高 pg_stat_statements.max 的实际内存成本是多少 - 比如说 100k 或 500k（默认为 5k）。设置这么高的水平是否安全，会不会是这样高水平的负面影响？通过 logstash/fluentd 将统计信息汇总到外部数据库中是否是超过特定规模的首选方法？

Answer 1

1.

根据我的阅读，它对查询进行哈希处理并将其保存在 DB 中，将文本保存到 FS。所以下一个问题更值得期待，然后是共享内存过载：

如果积累了很多长查询文本，外部文件可能会增长 大到无法控制

文本的哈希值比文本小得多，我认为您不必担心与长查询相比扩展内存消耗。特别是知道扩展使用查询分析器（这将适用于 EVERY 查询 ANYWAY）：

queryid 哈希值是在解析后分析中计算出来的 查询的表示

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

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

2.

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

如果发生这种情况，作为一种恢复方法，pg_stat_statements 可以选择 丢弃查询文本，因此 pg_stat_statements 视图将显示空查询字段