pg_stat_statements 对性能有什么影响？

Question

我用来pg_stat_statements查找生产 PostgreSQL 13 中的慢查询。有两件事：

• 我不确定此扩展对性能的影响。

• 我可以做些什么来提高其性能吗？下面的查询需要 > 1 秒 - 有什么建议吗？

    -- add the plugin 
    create extension pg_stat_statements;
    select pg_stat_reset();
    select pg_stat_statements_reset();

进而：

-- find slow queries using the extension:

select * from pg_stat_statements order by total_exec_time desc limit 50;

Answer 1

从这里：

\n

\n

\n
• pganalyze 对性能有何影响？
\n

\n

pg_stat_statements扩展的性能开销很小

\n

\n
• 它需要一些额外的共享内存，并且会消耗大约 1% 的 CPU 时间。
\n

\n

\n

以下是PostgreSQL 贡献者的一句话：

\n

\n

我总是在生产数据库上启用它。所带来的好处完全值得\n轻微的性能损失。

\n

特别是在生产数据库上，您想知道哪些语句导致最痛苦并且应该进行优化。

\n

\n

从这里开始（PostgreSQL 领域的另一个大人物）：

\n

\n

如果您使用 Postgres 并且尚未使用 pg_stat_statements，则必须将其添加到您的工具箱中。

\n

\n

这是旧的 - 两个单独的结果：

\n

\n

启用 pg_stat_statements 模块后，pgbench 得分为 468.2\ntps。在没有（加载）pg_stat_statements 模块的情况下，pgbench\nscore 为 470.3 tps。差异（开销）仅为 0.5%

\n

\n

     - Shared Buffers : 2048MB\n     - Checkpoint Segments : 32\n     - WAL Buffers : 1024kB\n     - Pgbench: Scale factor 10, 1,000 Transactions * 32 Clients\n

\n

在某些（恕我直言，专门的）条件下，他发现性能会受到 10% 的影响。

\n

让我印象深刻的是，第一个测试是一个更像“服务器式”的场景。

\n

全面的：

\n

事实上，PostgreSQL 领域的所有大玩家（高度）都推荐它，而且这里或 StackOverflow（我可以找到）上都没有这样的查询："I enabled pg_stat_statements" and now my server is running slowly"，这似乎是该工具的好兆头。分数。

\n

综上所述，没有什么可以替代在您自己的系统上使用您的硬件、软件和网络配置进行基准测试。最初，您可以尝试在安静时间打开和关闭它 - 但请记住，执行此操作需要重新启动服务器！

\n