Archives of the TeradataForum
Message Posted: Mon, 26 Nov 2001 @ 17:37:47 GMT
There are a lot of unknowns here, but I'd suggest changing the smaller table's primary index to be different than the large table. That should be enough "encouragement" for the Optimizer to take the strategy of duplicating the small table across all AMPs and doing a "RowHash Match Scan" into the big table. I believe the slightly higher CPU is a result of the cost of duplicating the small table. However, I think you'll find that this strategy will, in the long run, have a lesser impact on your system than having highly skewed queries.
Of course, there are a lot of unknown here such as;
- collecting stats on the small table
- the growth pattern of both tables
- the number of row in each table
- the size of your system
Hope this helps.
Thomas F. Stanek
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|