postgresql – 查询执行者 – 上一步的开始与下一步的结束不重叠

postgresql – 查询执行者 – 上一步的开始与下一步的结束不重叠,第1张

概述我看一下Postgres查询计划,我注意到上一步开始时间与下一步结束时间不重叠,所以我想知道间隙时间花在哪里? 为此查询编辑了字段名称. 如下所示,查询执行器有两个步骤. 下一步“索引扫描”结束于5730.776(实际时间),但根步骤开始于19199.316(实际时间).我的问题是5730.776到19199.316之间发生了什么? postgres 9.1 explain analyze sel 我看一下Postgres查询计划,我注意到上一步开始时间与下一步结束时间不重叠,所以我想知道间隙时间花在哪里?

为此查询编辑了字段名称.

如下所示,查询执行器有两个步骤.
下一步“索引扫描”结束于5730.776(实际时间),但根步骤开始于19199.316(实际时间).我的问题是5730.776到19199.316之间发生了什么?

postgres 9.1

explain analyze select a_ID,b_ID,c_ID,d_ID,e_ID,mydate,f,sum(used) usedfrom report A where mydate >= '2013-05-01' and mydate  <= '2013-08-30'group by a_ID,date,f;                                                                                                      query PLAN---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- HashAggregate  (cost=412378.59..418074.28 rows=569569 wIDth=70) (actual time=**19199.316**..25518.672 rows=4935988 loops=1)   ->  Index Scan using report_dateonly_IDx on report a  (cost=0.00..298464.83 rows=5695688 wIDth=70) (actual time=0.033..**5730.776** rows=5816028 loops=1)         Index Cond: ((date >= '2013-05-01 00:00:00'::timestamp without time zone) AND (date <= '2013-08-30 00:00:00'::timestamp without time zone)) Total runtime: 29148.500 ms
解决方法 您可能对 this series of blog posts on understanding query plans感兴趣.

在您的情况下,您误解了每个成本/时间中的两个数字代表什么.它们不是 *** 作的开始和结束,而是(大致)第一行之前的成本/时间,以及包括所有行的成本/时间.

Depesz给出了一个具有“成本= 22.88..23.61”的排序 *** 作的例子 – 准备数据的成本很高,因为你必须先对所有内容进行排序才能返回任何内容;实际返回它的成本要低得多,因为它只是绕过你的排序列表.

所以在你的例子中,19199.316并不意味着HashAggregate在t = 19199.316之前不会开始运行,这意味着直到t = 19199.316,HashAggregate才会出现数据,因为它仍然在准备东西.

实际上,一旦Index Scan开始返回它,HashAggregate就会开始处理数据,这是在t = 0.033;通过t = 5730.776,索引扫描找到了所有相关的行,但是HashAggregate仍在处理它们.在t = 19199.316时,HashAggregate准备开始将数据返回到其父级(在本例中是最终结果),并且在t = 25518.672时,它已完成返回它们.

Depezs还有一个工具可以将查询计划解释为表格形式; here’s your plan.请注意,HashAggregate显示的是19787.896的“独占时间” – 这是进行散列所需的时间,忽略了输入数据的来源.

总结

以上是内存溢出为你收集整理的postgresql – 查询执行者 – 上一步的开始与下一步的结束不重叠全部内容,希望文章能够帮你解决postgresql – 查询执行者 – 上一步的开始与下一步的结束不重叠所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1160114.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-01
下一篇 2022-06-01

发表评论

登录后才能评论

评论列表(0条)

保存