１. 如果能用greenplum3.3.X，就不要使用greenplum4.X。
原因： a. greenplum4.x看起當primary節點出現問題時，可以切換到mirror節點，繼續提供服務，當mirror節點恢復後，可以做增量同步。增量同步是一個大的亮點。
但實際上，greenplum4.x大量的的bug導致的的不穩定完全抵消了這個優點。當機器內存緊張時，mirror經常與主庫不同步。而每次不同步後要做停庫恢復，當
數據庫比較大的時候（如50T以上時），每次同步的時候經常需要2個小時以上。
同時greenplum4.x的primary節點與mirror節點是通過物理塊同步的。如果因為軟件bug把主庫搞掛了，那麼即使切換
到備庫上，備庫也一樣起不來。而greenplum3.3.x是通過邏輯同步的，也就是把DML和DDL同時發到primary和mirror執行，這樣即使軟件有bug導致primary起不來，切換到mirror還是可以起來的。
2. 當GP4.X 由於如內存耗盡等原因hang了之後，停數據庫時，最好不好直接使用gps
top -af命令直接停整個數據庫，按下面的步驟將安全很多：
a. 每一步，先停master: gpstop -amf，或gpstop -am -M immediate
b. 再啟動master: gpstart -am
c. 最後再gpstop -af
這個操作的核心是先把master給停掉。在greenplum異常hang住後，如果按標准的gpstop -af，很可能出現數據不一致，數據庫無法啟動的問題，這可能是greenplum的bug，我就遇到幾次這樣的問題，停庫後，數據庫無法啟動，報一些xlog錯誤的問題，讓EMC的專家上來也無法把數據庫搞起來，還好我們在文件系統上有快照，最後把文件系統閃回到2個小時前的快照上，數據庫才正常打開。後來使用這個操作步驟，這個問題就再也沒有也現過。
3. 關於GP的分區表
a. GP宣稱支持無限級分區，但實際上使用中，最好只用一級分區。另對小表最好就不要做分區了。GP本身就是在機器間做了數據水平拆分了，所以使用一級分區後，單個表的大小就不會很大。在greenplum和ＰostgreSQL中，分區實際上並不是真正的分區，而是通過表繼承來實現的。每個分區實際上是一個單獨的表，而每個表都是一個單獨的文件，當訪問這個表時，即使只訪問其中一個分區，但在生成執行計劃過程，greenplum會這個分區表所有分區的文件，還會地每個分區表做pg_relation_size()操作，這樣就會變得很慢。
b. 如果是一張包括幾百個分區的分區表，如果業務邏輯可以直接查詢分區表，那麼直接查詢分區表吧，這樣會快很多，原因同上。
例表：mytable，分區鍵為mydate，下面的SQL
select * from mytable where mydate='2012-03-08'
換成：
select * from mytable_1_prt_p20120308;
則性能會更好。
c. 盡量不要有空分區，原因同上。
４. 關於GP的統計信息
由於greenplum執行SQL的方法是先在master上把執行計劃生成好，
然後再發到底下的各個segment節點上執行，所以一般情況下統計信息只在master上有用，而在segment沒有太大用處。
GP是由下面的兩個參數為控制統計信息的收集的
gp_autostats_mode
gp_autostats_on_change_threshold
gp_autostats_mode參數可以取的值有三個：
none
on_change
on_no_stats
當設置為“none”為禁止收集統計信息，而設置為"on change"時，當一條DML執行後影響的行數超過gp_autostats_on_change_threshold參數
指定的值時，會執行完這條DML後再自動執行一個analyze 的操作來收集表的統計信息。
當設置為“no_no_stats“時，執行完DML語句後，發現這張表沒有統計信息，會自動執行analyze 來收集這張表的統計信息。
greenplum4.x的analyze的執行方法與greenplum3.x的方法是完全不一樣的。
greenplum3.x的方法是把analyze 語句直接發到各個segment上。
而greenplum4.x的analyze實際上是在master上直接執行很多個收集統計信息的SQL來收集統計信息的。
從實際的使用中看，greenplum3.x的方法的性能好，而greenplum4.x的性能比較差。原因是greenplum4.x在master上發SQL，
這些SQL由於有group，所以會發數據重分析，即使數據很小，重分布總是會需要更長的時間，而greenplum3.X是把analyze語句直接發到segment上，
沒有重分布，因而性能要好很多。
所以對於greenplum4.x上，如果你有大量的運行時間在1分鐘以下的SQL，你會發現大量的時間消耗在收集統計信息上。
為了降低這一部分的消耗，你可以需要在建表時就明確把一些不需要收集統計信息的更去除掉，如下所示：
create table test(id int, name text,note text);
上面是已知道表列note不需出現在join列上，也不會出現在where語句的過濾條件下，因為可以把這個列設置為不收集統計信息：
alter table test alter note SET STATISTICS 0;
由此可見greenplum4.X收集統計信息的方法也是一個看上下很美感，實際上很差的方法，
