c



  
You can also define a simple join index on a single table. This permits you to hash some or
all of the columns of a large replicated base table on a foreign key that hashes rows to the
same AMP as another large table. In some situations, this may perform better than building a
multi-table join index on the same columns. The advantage comes from less under-the-
covers update maintenance on the single table form of the index. Only testing can determine
which is the better design for a given set of tables, applications, and hardware configuration.
The example on the facing page shows a technique where the join index is effectively
substituted for the underlying base table. The join index has a primary index that ensures that
rows are hashed to the same AMPs as rows in tables being joined. This eliminates the need
for row redistribution when the join is made.
Even though each single table join index you create partly or entirely replicates its base table,
you cannot query or update them directly just as you cannot directly query or update any
other join index.
In this example, the compressed format for a single table join index can be used.
ë

c
c  


ë 

  

  
  

  
 
 
 
!
J


 
The amount of PERM space used by the compressed multi-table join index (previous
example) and the single table join index is listed below. Remember that these tables are quite
small and note that the join index with repeating data requires less storage space.
à
 
  

  
  
   
Note that in this example that the single table join index uses more permanent space. However,
the single table join index has some columns (from the Orders table) that not part of the
compressed multi-table join index.