Home Page for the TeradataForum

Archives of the TeradataForum

Message Posted: Tue, 14 Jan 2003 @ 20:54:12 GMT

  <Prev Next>  
Next> Last>>  

Subj:   Strange Product Join?
From:   Harold D Kleven

We did an EXPLAIN on this simple statement...

explain select s.store_name, d.*
from store s,daily_item_sales d
where s.store_key = d.store_key

The _key fields are meaningless identifiers for the rows and the query produced the following with a ProductJoin in step #3 that we didn't expect. The field s.store_key is the primary index on Stores, d.store_key is not the primary index on Daily_Item_Sales

  1)First, we lock Daily_Item_Sales for access, and we lock store for access.  
  2)Next, we do an all-AMPs RETRIEVE step from store by way of an all-rows scan with no residual conditions into Spool 2, which is duplicated on all AMPs. The size of Spool 2 is estimated with high confidence to be 15,624 rows. The estimated time for this step is 0.19 seconds.  
  3)We do an all-AMPs JOIN step from Spool 2 (Last Use) by way of an all-rows scan, which is joined to Daily_Item_Sales. Spool 2 and Daily_Item_Sales are joined using a product join, with a join condition of ("Store_Key = Daily_Item_Sales.Store_Key"). The input table Daily_Item_Sales will not be cached in memory, but it is eligible for synchronized scanning. The result goes into Spool 1, which is built locally on the AMPs. The result spool file will not be cached in memory. The size of Spool 1 is estimated with low confidence to be 359,563,834 rows. The estimated time for this step is 1 hour and 47 minutes.  
  4)Finally, we send out an END TRANSACTION step to all AMPs involved in processing the request.  
  ->The contents of Spool 1 are sent back to the user as the result of statement 1. The total estimated time is 1 hour and 47 minutes.  

Why was a Product Join used?

  <Prev Next>  
Next> Last>>  
  Top Home Privacy Feedback  
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 28 Jun 2020