Archives of the TeradataForum
Message Posted: Mon, 30 Jun 2003 @ 19:39:26 GMT
At the end of the day, although Teradata probably could do what you're asking, the chosen route is likely to be faster. A couple of things to think about in these join plans.
1) the BMSMS step is pulling ROWID values from the multiple NUSI's, not ROW HASH values.
2) the join between your Calendar and T1 tables is done via ROW HASH values.
Therefore, the above two steps use different items of information.
Think about the processing that Teradata is doing on it's chosen join plan. Once it's got the desired ROW HASH values from the Calendar table, these are then used to access the NUSI on column T1.C. The result of this access is a list of ROWID's. Using this list, Teradata can now go directly to the row that it needs. Whay would it search another index to further qualify rows? It simply needs to retrieve the row, check the additional columns to determine finally if the row identified by one NUSI (T1.C) meets all criteria.
Does that make sense?
|Copyright 2016 - All Rights Reserved
|Last Modified: 15 Jun 2023