Home Page for the TeradataForum
 
https:

Archives of the TeradataForum

Message Posted: Wed, 20 Apr 2005 @ 21:40:32 GMT


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


Subj:   Re: Problem with PPI Table Creation?
 
From:   Michael Larkins

Hi:

I think the issue for not allowing UPI when partitioned on a non-PI column is that forever Teradata has used the hashed PI values to determine which block to store the row. Therefore, all PI values that are the same ended up in the same block and were easy to determine whether or not they were unique.

With PPI, the data is not stored in hash sequence of the PI values. Instead the data is stored in sequence by the partitioning data value. Therefore, rows that have the same PI value but are in two different partitions means the data is in two different blocks. Therefore more I/O required. The same value could be in every partition, whether or not there was a value, Teradata would have to check. Therefore, it would seem to follow that duplicate checking could be a much more monumental task than it is without PPI and we know how bad it can be today.

That is my take on Carrie's posting.


Regards,

Michael Larkins
Certified Teradata Master
Certified Teradata SQL Instructor



     
  <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