Archives of the TeradataForum

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

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

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>>