Well, this depends on many factors.
At the end both of them will do the trick but there are things to consider
You will be building a complete replica of both huge tables joined together -> huge space consideration
Every insert/update/delete to one of the tables will result in the system updating the JI aswell -> slower inserts, updates, deletes.
The JI will serve only the query(s) it was designed for -> Not flexible if queries request data not in the JI
-
Single table join indexes
You will be building a replica of one of the tables hashed on a column of your choice (join column), different from the PI. This rehashing will result in joined rows to be residing on the same AMP therefore achieveing better join performance.
Since only one table is replicated in the JI, then you save the overheads of the multi-table join indexes.
I'm for the single table join index. I think that you can try both approaches and compare their advantages/drawbacks with the ones listed above.
Well, this depends on many factors.
At the end both of them will do the trick but there are things to consider
You will be building a complete replica of both huge tables joined together -> huge space consideration
Every insert/update/delete to one of the tables will result in the system updating the JI aswell -> slower inserts, updates, deletes.
The JI will serve only the query(s) it was designed for -> Not flexible if queries request data not in the JI
You will be building a replica of one of the tables hashed on a column of your choice (join column), different from the PI. This rehashing will result in joined rows to be residing on the same AMP therefore achieveing better join performance.
Since only one table is replicated in the JI, then you save the overheads of the multi-table join indexes.
I'm for the single table join index. I think that you can try both approaches and compare their advantages/drawbacks with the ones listed above.