根据Postgres pg_stat_statements文档：
该模块需要额外的共享内存 pg_stat_statements.max。请注意，无论何时使用此内存 即使pg_stat_statements.track设置为none，也会加载模块。
还有：
代表性查询文本保存在外部磁盘文件中 不要消耗共享内存。因此，即使是非常冗长的查询文本 可以成功存储。但是，如果有很多长查询文本 累积后，外部文件可能会变得难以管理。
从这些不清楚高pg_stat_statements.max的实际内存成本是多少 - 比如100k或500k（默认为5k）。设置高水平是否安全，可能是这种高水平的负面影响？通过logstash / fluentd将统计数据汇总到外部数据库是否是超过特定大小的首选方法？
答案 0 :(得分：2)
<强> 1
根据我的阅读，它散列查询并将其保存在DB中，将文本保存到FS。因此，下一个问题是更多的预期，然后重载共享内存：
如果累积了很多长查询文本，外部文件可能会增长 无法控制的大量
文本的散列比文本小得多，我认为你不应该担心比较长查询的扩展内存消耗。特别是知道该扩展使用查询分析器（适用于每次查询 ANYWAY ）：
在解析后分析上计算queryid哈希值 查询的表示
将pg_stat_statements.max设置为10倍，我认为共享内存应该增加10倍。增长应该是线性。 在文档中没有这么说，但从逻辑上讲应该如此。
如果将设置设置为不同的值是安全的，则没有答案，因为没有其他配置值和HW的数据。但是，由于增长应该是线性的，请考虑以下答案：“如果将其设置为5K，并且查询运行时几乎没有增长，那么将其设置为50K将几乎不会延长10倍”。顺便说一句，我的问题 - 谁来挖掘50000个缓慢的陈述？ ：）
<强> 2
此扩展程序已对“无价值”语句进行预聚合。您可以直接在DB上选择它，因此将数据移动到其他数据库并在那里选择它只会给您卸载原始数据库并加载另一个数据库的好处。换句话说，对于原始查询，您可以节省50MB，但在另一个上花费相同。是否有意义？对我来说 - 是的。这就是我自己做的。但我也保存了声明的执行计划（这不是pg_stat_statements扩展的一部分）。我相信这取决于你拥有什么以及拥有什么。绝对没有必要只是因为一些查询。除非你有这么大的文件，扩展可以
作为恢复方法，如果发生这种情况，pg_stat_statements可以选择 丢弃查询文本，然后放入所有现有条目 pg_stat_statements视图将显示空查询字段