【问题标题】:Postgres EXPLAIN ANALYZE is much faster than running the query normallyPostgres EXPLAIN ANALYZE 比正常运行查询快得多
【发布时间】:2010-08-06 02:12:08
【问题描述】:

我正在尝试优化 PostgreSQL 8.4 查询。在大大简化了原始查询之后,试图找出是什么让它选择了一个糟糕的查询计划,我到了在 EXPLAIN ANALYZE 下运行查询只需要 0.5s 的地步,而运行它通常需要 2.8s。很明显,EXPLAIN ANALYZE 向我展示的不是它通常所做的,所以无论它向我展示什么都是无用的,不是吗?这里发生了什么,我如何查看它的实际作用?

【问题讨论】:

  • 查询是否返回大量数据?我的理解是EXPLAIN ANALYZE 会丢弃数据——也许您正在赢得时间,而不必通过管道或网络连接传输数据?
  • 大约 75,000 行,所以我不会说“很多”。当然不应该在 LAN 上花费太多时间。
  • 显然,如果您要达到 100Mbps 的传输速率,则需要大约 1.3 秒(大约 16.25MB 或大约 220KB/行)的数据量
  • 不,行非常小。更像是每行 50 个字节。

标签: sql postgresql sql-execution-plan


【解决方案1】:

当您使用 EXPLAIN ANALYZE 手动运行以尝试优化查询时,数据页很可能位于 OS 磁盘缓存中。当在正常环境中运行时,页面可能已经不在缓存中并且必须从磁盘中获取,从而增加了运行时间。

【讨论】:

  • 我不明白 - 如果它们在我运行 EXPLAIN ANALYZE 时在缓存中,那么为什么当我在没有 EXPLAIN 的情况下立即运行时它们不在缓存中?
  • 对不起,我误解了顺序。现在,我会说差异更有可能是网络吞吐量。我建议添加一个 LIMIT 子句并尝试不同数量的记录(如 1、5、10、100、1000、10000 等),直到达到最大值并比较时间。我猜它会大致按“a+(t*n)”缩放,其中 a 是您的 EXPLAIN ANALYZE 时间,t 是每秒传输的行数的粗略常数,n 是您的行数。显然,这并不准确,但我猜它会趋向于它。
【解决方案2】:

它显示的时间更少,因为:

1) EXPLAIN ANALYZE 显示的总运行时间包括执行器启动和关闭时间,以及运行任何触发的触发器的时间,但不包括解析、重写或计划时间。

2)由于没有输出行传递给客户端,因此不包括网络传输成本和I/O转换成本。

警告!

EXPLAIN ANALYZE 增加的测量开销可能很大,尤其是在 gettimeofday() 操作系统调用缓慢的机器上。因此,建议使用EXPLAIN (ANALYZE TRUE, TIMING FALSE)

【讨论】:

  • 谢谢。我实际上将数据下载到我的机器上,但仍然需要大约 13 秒,而在 EXPLAIN ANALYZE 中大约需要 0.5 秒。如何优化数据写入?
猜你喜欢
  • 2020-03-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-12-11
  • 2021-03-09
  • 2012-09-16
  • 2019-01-17
  • 1970-01-01
相关资源
最近更新 更多