如何让TD避免使用单放大器检索?

时间:2017-03-07 15:04:56

标签: sql performance query-optimization teradata spool

我有这样的疑问:

select * from view -- not very simple logic
where report_date between date'2016-01-01' and date'2016-12-31';

然后我花了很大的时间间隔:

TD选择了这样的计划:

3) We do an all-AMPs RETRIEVE step from Spool 25 (Last Use) by way of
     an all-rows scan with a condition of ("(REPORT_DT >= DATE
     '2016-01-01') AND (REPORT_DT <= DATE '2016-12-31')") into Spool 36
     (all_amps) (compressed columns allowed) fanned out into 3 hash

但如果我没有那么大的间隔,它决定对每个数据采取简单的放大器检索:

   select * from view -- not very simple logic
    where report_date between date'2016-06-01' and date'2016-12-31';

239) We do a single-AMP RETRIEVE step from
     tableName1 by way of the unique
     primary index "tableName1.gregor_dt =
     DATE '2016-08-08'" extracting row ids only with no residual
     conditions locking row for access into Spool 43 (group_amps),
     which is built locally on that AMP.  The size of Spool 43 is
     estimated with low confidence to be 221 rows.  The estimated time
     for this step is 0.00 seconds.

1)由于假脱机问题,第二次查询失败。如何强制teradata使用第一个计划?

upd1

  • 没有双重演员,只是从一种日期格式转换为 另一个。
  • 两个计划都使用重新分配,除了指出的地方我没有差别。
  • TD过高估计行数,最多2-3次(我在评论中提供了错误信息)
  • DEV中的信息和统计信息几乎相同。然而,DEV服务器的AMPS和节点数量减少了2倍,此外每个放大器明显不那么强大。然而,开发中的TD开始决定使用第一个&#34; good&#34;计划更短的间隔。我们怎么能愚弄&#34; PROD服务器关于那一点?)

1 个答案:

答案 0 :(得分:0)

我做到了!为了让它工作只需要两次欺骗TD)

查询的想法是获取表,然后产品将其加入Sys_Calendar,然后应用row_number和一些逻辑。丢弃统计数据可能有效,但TD可能会使用抽样和兑现,这最终会影响您的工作。这就是我在视图中应用expand +子查询的原因:

...
FROM   (    SEL cdate as cdate FROM (SELECT   DISTINCT      BEGIN      (tp) (NAMED cdate) 
    FROM           Sys_Calendar.CALDATES
    EXPAND       ON PERIOD (date '2014-01-01', current_date + 1) AS tp
    BY INTERVAL '1' DAY FOR PERIOD (date '2014-01-01',  current_date  + 1)
    ) A)  cldr
...

之后,我可以使用where子句申请和期望。

新计划的速度提高了15倍,即使是好的&#34;计划!