Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Mon, 11 Sep 2001 @ 00:42:44 GMT


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


Subj:   Re: SELECT vs. Temporary Table
 
From:   Eric J. Kohut

Jim, I will take a shot at this question.

I believe Igor is familiar with RDBMS's that either materialize a copy of the table with an indexed access path or with a materialized view via a concept similar to our join index / aggregate index functionality.

Igor, I think that you should get a very good overview of Teradata from someone (possibly on this list) and how to use our system functions to provide the functionality that you are looking to provide.

Just know that in Teradata, there are often many ways to accomplish the same task.

I suggest trying the most simple approach first. Most of the time the simple approach provide many times to 100's times better performance than you are used to.

If you still need better performance then try adding additional structures like secondary indexes, join / aggregate indexing, summary tables, derived tables, etc... to improve performance.

The other alternative is to specify your requirements in a very detailed manner including performance expectations so someone on the list can help guide you in the right direction. However, this will probably be hard to do in a short period of time unless the scope is very narrow. I suggest hiring someone to help you build up your Teradata expertise and build your confidence in it's strengths. Education will also help in this area. The Teradata Design class (the old Physical Database Design class) is highly recommended.

My experience has been that less than 1 problem in 10,000+ (a large number) can't be accomplished in some manner and the problems that I deal with are fairly complex. Recently, we've even done 2 versions of a householding algorithm with Teradata. We often see 30 + table joins with 100's of spool tables, derived tables, and 10's of sub-queries etc... Normally, you can try just about any level of complexity that you can code.

Performance is a function of both size and complexity, but can often be largely offset by physical design choices.

Good Luck,

Eric

EJK
Eric J. Kohut
Senior Solutions Consultant - Teradata Solutions Group - Retail
Certified Teradata Master
NCR Corp.



     
  <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