gpdb在進行join查詢時,可能會產生motion結點
根據官方文件，總共有這幾種motion：
redistribute 重分布（用hash取模的方法把join欄位重分布到各個segment，相當等於生成了一張分布鍵為join欄位的臨時表）
explicit redistribute 精確的重分布（待查資料）
broadcast 廣播（把一張表的資料全部複製到所有segmeent上，一般做小表廣播）
gather 彙總（彙總到master的操作，不一定有，比如create table as select語句，只需要分發資料到各個segment即可）
join兩邊的字段都是分布鍵，沒有motion操作。這個很好理解，a表和b表分布鍵相同的值都在同乙個segment上了，不需要轉移資料
大表join大表，其中乙個join欄位是分布鍵，另乙個不是，此時非分布鍵的表會被重分布。這個也好理解，廣播是資料量*segment數的代價，但重分布是1個資料量的代價。重分布後， a表和b表相同值的行都在同乙個segment上。
小表join大表，其中小表用了分布鍵，大表不用分布鍵，此時會廣播小表。那為什麼不會重分布小表呢？因為小表的join條件已經是分布鍵了，重分布後的資料不會改變的，所以只能對小表進行廣播。而無論對大表進行重分布或廣播，代價都要比廣播小表高得多
小表join大表，其中小表不用分布鍵，大表用分布鍵，此時重分布小表，毫無疑問
大表join大表，其中乙個不用分布鍵，此時重分布不使用分布鍵的表
兩張表的join條件都不是分布鍵，此時重分布a表+重分布b表代價最低
對Sql Server執行計畫的淺顯了解。
一名大三的小學生，今天開始我的第一篇部落格，最近隨便做了乙個簡易的酒店管理系統，對sql執行計畫有了初步的了解。檢視上面語句的預估執行計畫，在工具欄中有這個按鈕 聚集索引掃瞄被稱為index scan，這是需要掃瞄全表。聚集索引查詢英文是index seek.這個就不需要掃瞄表，而是根據索引定位。我...
MYSQL NULL 對查詢的影響
在建立表時，經常要給某些列設定 not null 的約束。可是為什麼我們盡量不使用 null 呢？這裡記錄幾個簡單的例子 在使用 distinct 時，null 也被視為一類資料，null 存在於多行中時，也會被合併為一條 null 的資料.所有包含 null 的計算，結果必然是 null。如 1 ...
查詢計畫中的掃瞄和查詢效率比較說明
1.index seek 索引查詢 索引查詢意味著查詢優化器使用了資料表上的非聚集索引來查詢資料。效能通常會很快，尤其是當只有少數的資料行被返回時。2.clustered index seek 聚集索引查詢。這指查詢優化器使用了資料表上的聚集索引來查詢資料，效能很快。3.clustered inde...