【发布时间】：2017-07-27 20:35:46
【问题描述】：
我有这样的疑问：
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
但如果我采取的间隔不是那么大，它决定对每个数据进行简单的 amp 检索：
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 使用第一个计划？
更新1：
- 没有双重转换，只是从一种日期格式转换为 另一个。
- 两个计划都使用重新分配，除了指出的地方，我没有区别。
- TD 高估了行数，最多 2-3 次（我在评论中给出了错误的信息）
- 我们在 DEV 中拥有几乎相同数量的信息和统计数据。然而，DEV 服务器的 AMPS 和节点数量减少了 2 倍，此外每个 amp 的功能明显降低。然而，开发中的 TD 开始决定在较短的时间间隔内使用第一个“好”计划。我们如何才能在这一点上“愚弄”PROD 服务器？）
【问题讨论】：
-
很可能是因为您的标准
prd3_1_db_dmmonmis.t_greg_work_calendar.gregor_dt = DATE '2016-08-08将您限制为单个放大器上的数据。你展示的这两个解释步骤彼此完全没有关系。 -
@Andrew：这是 TD15.10 中的新功能，
BETWEEN可能会在优化之前解析为唯一值列表。 -
奇怪，第二个查询遇到了假脱机问题，可能为以后的步骤解释更改。您可能会尝试通过添加一些不必要的 CAST（如
Cast(Cast(report_date AS TIMESTAMP) AS DATE)）来混淆优化器，但如果完全错误，请检查估计的行数。 -
@dnoeth：所以上面的查询可能会为
between中的每个不同日期获取一堆单个放大器检索？我们已经 14 岁了，所以我不能尝试。 -
@Andrew：是的，正确的。
标签： sql performance query-optimization teradata spool