Home Page for the TeradataForum

Archives of the TeradataForum

Message Posted: Sun, 03 Nov 2002 @ 19:10:27 GMT

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

Subj:   Re: Does Teradata have anything similar to Procedural caching (supported with SQL Server)
From:   Kohut, Eric J


I'd actually like to see the SQL and Table definitions for Teradata. I don't want to assume that for example the Unique Columns (PI) are the same between the two tables.

If the PI's are not the same then there are possibly better ways to service this request and provide improved response time and scalability. I can provide examples if this is the case.

The fact that the Primary Indexes are the same in both RDBMS's doesn't really tell me anything either. Physical design for each RDBMS should be different to take advantage of each RDBMS strengths.

Also, you mention that there are two subqueies which I'd like to review.

As far as the testing approach, You mention looping. Are these serial, or do you fire off all the requests in parallel. Seeing the scripts would help here.

If you are using the Primary Index to access these tables and the PI is the same for both tables, then you need to try to fire these off in parallel to get the best performance out of Teradata.

Teradata is more of a throughput machine than a response time machine so that if you submit these requests serially we may take longer to service the requests due to the time lag in receiving them, but if submit the requests in parallel (similar to these requests being received by independent clients at the same or nearly the same time) then Teradata will service these in parallel. If you don't want to change your script, then just run more instances of it in parallel for Teradata on each client or more clients and measure the total throughput in a given time. If you find this approach to be unfair, you could always run more for both but you might have to run very many instances with continually increasing numbers to see where each systems throughput max lies. I'd need to know much more about your application to know what the arrival rate would look like for the real world work load in order to know if this throughput model is better for servicing your particular application.

For example, many centralized system (Web) can increase the number of threads or application instances in their applications to help parallelize the request arrival rate in order to provide better application throughput.

God Luck,


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: 28 Jun 2020