为此查询编辑了字段名称.
如下所示,查询执行器有两个步骤.
下一步“索引扫描”结束于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 – 查询执行者 – 上一步的开始与下一步的结束不重叠所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)