1. 在完成大批量數據裝載之後，針對目標表總是進行vacuum analyze操作。
2. 表的佈局：
儘量把數據分佈鍵放在最前面，如果是分區表，那麼接下來是分區鍵，並且在此基礎上建議按照數據類型寬度從大到小的順序排列比如先8 byte的列，再4字節，再2字節。
3. 數據分佈鍵的選擇：
數據分佈均勻是保證GP高效並行處理能力的基礎。因此定義表時，如果選用HASH分佈策略，保證數據分佈均勻是獲取高性能的關鍵所在。選擇的依據遵從三大原則，第一個就是首先保證前面提到的所有節點數據存放是均勻的。第二，如果經常進行大表連接，那麼儘量把連接鍵定義成數據分佈鍵（如果多個列作爲數據分佈鍵，他們應該都出現在連接中，否則還是會造成無效廣播），這樣儘量減少無效的interconnect。第三，儘量保證where條件產生的結果集的存儲也儘量是均勻的。
4. GREENPLUM同時支持行存和列存方式，那麼到底該怎麼選擇？ 如果記錄需要update/delete，那麼只能選擇非壓縮的行存方式。對於查詢，如果選擇的列的數量經常超過30個以上的列，那麼也應該選擇行存方式。如果選擇列的數量非常有限，並且希望通過較高的壓縮比換取海量數據查詢時的較好的IO性能，那麼就應該選擇列存模式。但是需要注意的是，如果是列存分區表，每個分區的每個列都會有一個對應的物理文件。比如有100個分區，100個列，那麼就會產生10000個文件，默認情況下，這些文件都會放在一個目錄中。這可能會導致兩方面的問題，一個是訪問數據時有可能超越linux上允許同時打開文件數量的上限。另一個是在同一個目錄內，存放過多的文件，會導致DDL命令的效率很差。解決這兩個問題，一個是儘量在SQL中使用事實表的分區鍵作爲條件，或者儘量指定需要訪問的事實表分區，以減少文件的訪問。另外，應該創建不同的表空間（相當於不同的系統目錄），把分區放入不同的表空間。
5. SQL優化的考慮：
explain和explain analyze是有區別的。explain是基於統計，給出執行計劃，他不會真正執行SQL，因此沒有執行統計。explain analyze會真正執行SQL因此會提供執行過程中真實資源消耗統計，但是對在線系統可能影響會較大。
如果是從超大結果集合中返回非常小的結果集（不超過5%），建議使用BTREE索引（非典型數據倉庫操作）。表記錄的存儲順序最好與索引一致，可以進一步減少IO（好的index cluster），where條件中的列用or的方式進行join，可以考慮使用索引，還有就是記錄很多，鍵值大量重複時，比較適合使用bitmap索引。
7. 函數和存儲過程的書寫：
雖然支持遊標但是，儘量不要使用遊標方式處理數據，而是應該把數據作爲一個整體進行操作。