具有低成本和行数的慢速红移查询答案

【问题标题】：Slow redshift query with low cost and number of rows具有低成本和行数的慢速红移查询
【发布时间】：2018-08-28 01:08:30
【问题描述】：

我有一个 Redshift 查询，结果生成了以下查询计划：

XN HashAggregate  (cost=4.00..4.06 rows=1 width=213)
  ->  XN Hash Join DS_DIST_ALL_NONE  (cost=0.02..3.97 rows=1 width=213)
        ->  XN Hash Join DS_DIST_NONE  (cost=0.00..3.93 rows=1 width=213)
        ->  XN Hash  (cost=0.01..0.01 rows=1 width=8)
              ->  XN Seq Scan on response_entities re  (cost=0.00..1.96 rows=157 width=85)
              ->  XN Hash  (cost=0.00..0.00 rows=1 width=208)
                    ->  XN Seq Scan on response_views rv  (cost=0.00..0.00 rows=1 width=208)
              ->  XN Seq Scan on dim_date dd  (cost=0.00..0.01 rows=1 width=8)

查询不会广播或重新分配任何数据，成本非常低，并且不需要读取大量行。它实际上不返回任何行，并且它的所有步骤都不是基于磁盘的。

AWS 控制台上的执行细节显示如下：

我没有包含查询，因为我不是在寻找为什么这个特定查询需要 3 秒才能完成的原因。我不断看到与此类似的执行时间表，我试图理解为什么即使每个步骤只需几毫秒即可完成，但查询最终会花费更长的时间。没有其他并发查询正在执行。

所有这些时间都花在查询编译上吗？这是预期的吗？我有什么遗漏吗？

【问题讨论】：

标签： amazon-redshift

【解决方案1】：

查询编译似乎是造成这种情况的原因。这个查询慢编译段。

select userid, xid,  pid, query, segment, locus,  
datediff(ms, starttime, endtime) as duration, compile 
from svl_compile 
where query = 26540
order by query, segment;

更多关于 svl_compile 的信息可以在here找到。

this article 解释了同样的问题以及如何减少编译次数（或解决方法）。

【讨论】：