併發管理涉及兩方面的問題
一方面是保證併發事務一致性，另一方面是有效管理資源佇列。
greenplum併發和事務管理基於postgresql單節點的mvcc（multi-version concurrency control，多版本併發控制）和快照特性，並開發了自有的、完備的分布式事務管理機制。postgresql對每個事務都會分配相應的事務id，對操作的資料行會附加隱藏的執行事務id
。例如，修改一行時，就會建立乙個該行的新版本，當乙個新的事務或者語句執行時會獲取乙個系統快照，快照中包含系統中事務的狀態和開始時間。接下來的操作就會根據這些資訊獲取、運算元據行，從而高效地完成併發的增刪改查。
greenplum在上述基礎上又引入了全域性分布式事務，通過在master節點獲取全域性快照來協調同步每個segment節點的工作，通過兩階段提交來確保事務在所有節點上的一致狀態。
資源佇列的作用在現實生活中也隨處可見。在銀行或者酒店有限的櫃檯前，如果大家都擠上去，可能每個客戶都得不到滿意的服務，但如果有乙個秩序良好的佇列，大家逐個來到櫃檯前辦理業務，那麼使用者體驗會更好。同理，面對有限的資料庫資源，如果瞬時使用者提交的語句太多，系統資源會分得太細，每個使用者的操作會變得非常緩慢，那麼通過資源佇列可以很好地解決這樣的問題。當建立資源組時，通過指定併發數量，就限定了在同一時刻該資源組允許併發執行的最大語句數，其他請求則需要排隊等待執行中的任一語句結束後才能被喚醒。
資源佇列在分析型的場景中應用得比較普遍，有些分析型語句需要的資源比較多，通過資源佇列進行限制可以讓每個語句依次快速完成，而不是每個語句特別慢地幾乎同時完成。即使對於事務型的語句，佇列限制也非常有幫助，可以防止突發的大量併發訪問導致系統不穩定。佇列限制提供了乙個公平的機制，使排隊等待的查詢按照提交的先後順序依次放行。有的使用者擔心greenplum這樣的分布式系統因為引入了分布式事務，會不會在處理短小的事務型語句時，由於分布式事務的開銷導致延遲偏高。最近，greenplum社群分析了這部分的**邏輯，通過減少事務鎖的衝突場景等手段優化鎖的管理，並且合併了postgresql後續版本的一些改進，例如大幅減少獲取鎖的開銷，以及將多個事務的提交合併為一組一次寫入事務日誌等。經過一系列優化後，greenplum處理一些短小查詢時非常得心應手，我們對比了單機postgresql 10和四節點的greenplum 6-dev，在同樣的120個併發情況下執行簡單的事務型查詢語句的情況，greenplum並不輸於postgresql。例如，不使用索引時，greenplum的tps可以達到單機postgresql的四倍。如下圖所示，橫座標代表併發數，縱座標代表tps，黑色的線是postgresql的資料，灰色的線是使用了資源組的greenplum的tps資料，可以看到，在這種情況下greenplum有非常好的表現
GreenPlum之程序會話管理篇
1.查詢指定庫下面的活動會話，procpid欄位表示會話proc select from pg stat activity where datname dbname 2.中斷查詢，表示上面查詢對應的procpid，下同 select pg cancel backend 3.中斷會話連線 select...
Greenplum簡明手冊
su gpadmin gpstart 正常啟動 gpstop 正常關閉 gpstop m fast 快速關閉 gpstop r 重啟 正常登陸 psql gpdb psql d gpdb h gphostm p 5432 u gpadmin 使用utility方式 pgoptions c gp se...
GreenPlum日常總結
1 計算佔比 保留小數點兩位，拼接 round a2.uv a1.uv a1.uv numeric 100,2 as ratio2 計算儲存 檢視外部表的儲存大小 select pg size pretty pg relation size ods.ods dev device info d ext...