Archives of the TeradataForum

Message Posted: Fri, 21 Feb 2003 @ 18:58:41 GMT

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

The Performance Optimization Guide and other Teradata manuals discuss many factors that could be contributing to your problem. The most obvious issues that you want to check up front are:

1.) Hash collisions - are you getting many duplicates of the same PI?

2.) Order of the input dataset - If the data coming into the job is in the order of the PI and there are lots of duplicates you're likely to be experiencing hot AMPs. Most of the rows are being processed and therefore work is being performed on a single AMP at a time.

3.) Dup row check - related to 1 above, if you have many duplicate values of the PI and the table is Multiset a dup row check will be performed. The higher degree of duplication will cause dup row checks to rise exponentially. You can disable this check by using a SET table but be aware that duplicates will be accepted

4.) Other concurrent workload and your priority - the obvious, contention from other queries relative to your assigned priority

5.) Network issues - you might be constrained on the network/channel over which the data is transmitted

I suggest that you check these items first. You are likely to find your problem there. If this does not provide relief then provide more details to the forum. Calculate the number of bytes attempted to be fastloaded. If the rows are wide then obviously it will take more time. Let us know what throughput you are observing, the workload, and your priority.

Hope this helps,

Doug Drake

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