Archives of the TeradataForum

Message Posted: Tue, 28 Jun 2005 @ 19:13:54 GMT

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

thanks Victor. I understand that the business attribute inclusion is the best way to define PI.

Consider the database performance now:

the same situation might occur if the parent table PI consists of ACCT_CODE (business key) and the child table PI consists of ACCT_CODE and SUBSCRIPTION_CODE (business keys). The index hash values still dont match for a parent record and a related child record. We can of course add more AMP power to the system and decrease execution time on an all-AMP scanning query.

Before you reply: Consider that parent and child tables have huge volumes of data. 100 million and counting.

I thought of hash and join indexes but ruled them out because of the storage space required. NUPI on child table with same attribute composition as the parent UPI might not gaurantee good distribution if the values in child table are not nearly singular.

SO how do you folks design the indexes on such related tables? Of course, considering the distribution and hashing will be the priority.

Feel free to correct me if I am wrong.

swapnil

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