GPDB在進行join查詢時,可能會產生Motion結點
根據官方文件，總共有這幾種Motion：
- redistribute 重分佈（用hash取模的方法把join欄位重分佈到各個segment，相當等於生成了一張分佈鍵為join欄位的臨時表）
- explicit redistribute 精確的重分佈（待查資料）
- broadcast 廣播（把一張表的資料全部複製到所有segmeent上，一般做小表廣播）
- gather 彙總（彙總到master的操作，不一定有，比如create table as select語句，只需要分發資料到各個segment即可）
根據參考資料1我的理解：
- join兩邊的欄位都是分佈鍵，沒有motion操作。這個很好理解，A表和B表分佈鍵相同的值都在同一個segment上了，不需要轉移資料
- 大表join大表，其中一個join欄位是分佈鍵，另一個不是，此時非分佈鍵的表會被重分佈。這個也好理解，廣播是
資料量*segment數的代價，但重分佈是1個資料量的代價。重分佈後， A表和B表相同值的行都在同一個segment上。 - 小表join大表，其中小表用了分佈鍵，大表不用分佈鍵，此時會廣播小表。那為什麼不會重分佈小表呢？因為小表的join條件已經是分佈鍵了，重分佈後的資料不會改變的，所以只能對小表進行廣播。而無論對大表進行重分佈或廣播，代價都要比廣播小表高得多
- 小表join大表，其中小表不用分佈鍵，大表用分佈鍵，此時重分佈小表，毫無疑問
- 大表join大表，其中一個不用分佈鍵，此時重分佈不使用分佈鍵的表
- 兩張表的join條件都不是分佈鍵，此時重分佈A表+重分佈B表代價最低
參考資料：