我有這樣的查詢:如何讓TD避免使用單個放大器檢索?
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使用第一個計劃?
upd1:
- 沒有雙發,從一個日期格式轉換隻是向 另一個。
- 這兩個計劃使用重新分配,除了指出的地方我沒有差異。
- TD高估的行數,最多2-3次(我給了有關在註釋錯誤信息)
- 我們幾乎在DEV信息和統計數據相同的量。但是,DEV服務器的AMPS和節點數量減少了2倍,另外每個放大器的功能也不那麼強大。然而TD中的開發人員決定在較短的時間間隔內使用第一個「好」計劃。我們該如何「愚弄」PROD服務器呢?)
很可能是因爲您的條件'prd3_1_db_dmmonmis.t_greg_work_calendar.gregor_dt = DATE'2016-08-08'限制您使用單個功放的數據。這兩個解釋你在那裏展示的步驟完全沒有關係。 – Andrew
@Andrew:這是TD15.10中的一項新功能,「BETWEEN」可能會在優化之前解析爲唯一值列表。 – dnoeth
奇怪的是,第二個查詢運行到後臺處理問題,可能解釋後續步驟的更改。您可能會嘗試通過添加一些不需要的CAST來混淆優化器,如Cast(Cast(report_date AS TIMESTAMP)AS DATE)',但檢查估計的行數是否完全錯誤。 – dnoeth