在《 【大資料之資料倉庫】選型流水記》一文中有提及，當時沒有測試GreenPlum的quicklz壓縮算法和ORCA查詢優化器，考慮到quicklz壓縮算法因為版權問題不會開源（詳情請參閱： https://github.com/greenplum-db/gpdb/blob/master/src/backend/catalog/quicklz_compression.c），今天我們就來補上已開源的ORCA查詢優化器這一段。
GreenPlum有2個查詢優化器：legacy query optimizer（簡稱LQO）和pivotal query optimizer（簡稱PQO），而後者就是傳說中的ORCA，我把之前LQO和PQO的TPCH對比測試做了簡要彙總，整理在本文，以飨各位同學。測試拓撲延續《【大資料之資料倉庫】基準測試之TPCH》中的測試環境，選擇了10GB和100GB兩種規格的資料集，以達到測試純記憶體、記憶體+磁盤這樣兩種場景。
10GB
10GB資料集的資料基本都在記憶體裡，沒有了磁盤IO開銷：
100GB
兩個測試結果顯示，PQO并沒有比LQO占明顯優勢啊，
為什麼？
這裡有一篇關于PQO的曆史：
https://www.pivotalguru.com/?p=971，簡單來說就是：LQO源自postgreSQL的查詢優化器，并對其進行了分布式改造，而PQO是對LQO的重構，增強了性能和可維護性。可是，還是回答不了前面的問題......
又翻到一篇關于GreenPlum 4.3版本釋出資訊的博文：
https://www.pivotalguru.com/?p=614，我把其中比較重要部分截圖出來如下：
這裡有對PQO（ORCA）做了比較具體的描述：1.優化了某些邊緣用例；2.優化了某些帶分區表、子查詢等特殊場景的性能。
看到這裡，頓悟了一下，我正在做的TPCH測試，屬于Ad-Hoc類型，才22個用例，相對于TPCDS決策支援類型來講屬于比較比較常用和常見的，而且對資料集中的事實表，我也确實沒有分區（想知道原因可以留言）......哦哦哦，難怪沒有優勢=_____=
那，如果換用TPCDS來對比測試，PQO會不會有優勢呢？我想這篇HAWQ測試可以告訴我們一些答案：
https://www.pivotalguru.com/?p=1045
看這裡：
《
【大資料之資料倉庫】選型流水記》
本文來自網易雲社群，經作者何李夫授權釋出。
原文位址：【大資料之資料倉庫】GreenPlum優化器對比測試
更多網易研發、産品、營運經驗分享請通路網易雲社群。