Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Wed, 07 May 2003 @ 16:02:20 GMT


     
  <Prev Next>   <<First <Prev
Next>
Last>>
 


Subj:   Re: Derived Table Handling in V2R5
 
From:   Walter, Todd A

The Derived table optimization works exactly like views. If an aggregation or other operation (eg analytic functions) is performed in the derived table or view, then that operation must be performed at that place in the plan to result in semantically correct results. What will happen for those cases is, where possible, conditions will be pushed across the boundary into the inner query to be evaluated as early as possible but the aggregation will be performed as specified.

The primary target of the optimization are the cases where the derived table only refers to a table or join with associated selection conditions. In this case, like with views, the derived table will be unwrapped and rewritten as a standard join or selection in the outer query. In this case, the ability to force precedence of the joins will indeed be removed.

As noted by Clay, there is another feature of V2R5 - partial/early group by - which should eliminate the need to define the location of the grouping operation in the query. The optimizer will notice that the aggregation can be performed over one table early in the plan, followed by joins to reference tables for instance. This is separate from the derived table optimization.



     
  <Prev Next>   <<First <Prev
Next>
Last>>
 
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016