postgresql – 查询执行者 – 上一步的开始与下一步的结束不重叠
我看一下Postgres查询计划,我注意到上一步开始时间与下一步结束时间不重叠,所以我想知道间隙时间花在哪里?
为此查询编辑了字段名称. 如下所示,查询执行器有两个步骤. postgres 9.1 explain analyze select a_id,b_id,c_id,d_id,e_id,mydate,f,sum(used) used from 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的“独占时间” – 这是进行散列所需的时间,忽略了输入数据的来源. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |