 |
 |
Archives of the TeradataForum
Message Posted: Wed, 15 Jan 2003 @ 12:35:43 GMT
| Subj: | | Re: Strange Product Join? |
| |
| From: | | Dieter N�th |
| | Given that the join is NOT a PI to PI join then one/both of the tables need to be moved. In this case the optimiser is guessing that
the Daily_Sales_Item table is large ("low confidence" typically means no stats) and it knows there are only 16K rows on Store. Rather than
having to move or sort the large table in order to do a row-hash match, the large table is simply left in situ and the small table is dup'd
on all amps and product joined. This is the plan you're seeing. | |
There are even less rows, because 16K is the number of rows in spool. As the table is duplicated on each AMP, you'll have to divide the
number of rows by the number of AMPs, e.g. if it's a 72 AMP system, there are only 15624/72 = 217 stores.
Dieter
| |
