關于PG在Shared buffers上的DOUBLE BUFFERING設計，一直是爭議極多的。有一些搞PG的朋友認為這是PG充分利用OS CACHE的一種特殊設計，是PG數據庫設計中比較優秀的地方。還有一些朋友則認為這是一種過時的設計，與當前數據庫技術的發展潮流所相違背的。前些天有幾個朋友談到這個問題，希望我寫篇位置表達下我的觀點。

以我這些年做數據庫優化的經驗來看，DOUBLE BUFFERING的設計如果算是一種技術上的進步，在這一點上我一直是不太認同的。眾所周知，現在幾乎所有的現代數據庫產品都是用AIO/DIO等方式來訪問底層存儲系統，只有PG目前還通過BUFFER/CACHE來讀取物理文件。隨著現代硬件的發展，BUFFERED IO的劣勢越來越顯現出來了。如果我們采用直接IO，繞過文件緩沖，那么就可以繞過BUFFER CACHE這一層，讓數據從文件到內存更為直接，這會大幅提升OS到數據庫緩沖的數據交換的吞吐能力，同時，因為DMA等技術的使用，可以讓文件IO消耗的CPU資源更少，讓系統更為高效。這對于大型數據庫系統來說絕對是十分必要的。PG數據庫越來越被用于大型OLTP系統，直接IO替代BUFFERED IO肯定可以有效增加大型系統的并發IO能力。

另外一個方面，操作系統是無法充分理解數據庫的PAGE訪問邏輯的，因此操作系統緩沖的效率比較shared buffers而言，要低的多。兩個分別由RDBMS和OS管理的分離的緩沖的效率肯定沒有一個獨立的數據庫緩沖高，這個應該也是廣大研發人員的共識。不過這句話成立的前提是數據庫緩沖區被設計的十分高效，其LRU算法也被設計的十分合理。通過分析Oracle DB CACHE的算法的改進，我們也了解到為什么Oracle的DB CACHE能夠保持那么高的DB CACHE命中率了。

既然使用統一緩沖，消除DOUBLE BUFFERING那么重要，那么為什么PG還在堅持使用DOUBLE BUFFERING呢？這個原因十分復雜，實際上最近這些年里，PG社區也在這方面做著不斷的努力。通過利用OS的AIO來替代當前bufmgr.c中的BUFFERD IO操作，不過PG的IO堆棧太長了，在大量的代碼中都存在和buffered io相關的內容，再加上PG的文件結構導致的預讀、連續塊訪問的IO合并等問題，要解決這個問題并不容易。在IO路徑上，不僅僅需要修改bufmgr.c，在smgr.c，xlog.c，到底層的md.c,fd.c，甚至backend等模塊中都有大量IO相關的代碼需要修改。這些修改不僅僅是在調用文件IO時的函數調用的修改，還涉及到異步IO模式的修改，以及IO優化、預讀等一系列的問題。因此這部分的修改中左雖然已經進行了數年，但是要出現在正是發布的版本中，依然還需要一定的時間。這也成為PG代碼中的XID64之外的又一個老大難的問題。

除此之外，在shared buffers的管理上，也需要做相應的優化，否則哪怕底層IO改為了AIO，buffer contention沖突也會讓一個大型的統一的數據庫緩沖的性能出現問題。比如在Oracle上遇到的buffer busy waits等待，可能會在PG上放大，從而在高并發訪問時引發嚴重的性能問題。

舉個最簡單的場景，那就是當多個backend需要訪問相同的一組PAGE的時候，PG目前的管理算法上海經常會出現lwlock等待方面的超時等問題。而Oracle從9i開始已經優化了這方面的算法，當多個并發的會話訪問相同的block的時候，首先為這個BLOCK申請db cache的會話會PIN住這個BUFFER HEADER，然后開始加載這個block（當然也包含IO合并以及預讀，多塊讀方面的算法優化），其他并發訪問相同數據的會話就會等待“read by another session”，這個等待事件是Oracle 10g才開始引入的，在9i中等待的依然是buffer busy waits，不過reason code（P3）參數是特殊的，從reason code可以缺別處這種特殊的熱塊沖突類型。當PG在這方面算法沒有做優化之前，就無法區分這種情況，也就無法與AIO配合，達到最低成本的開銷。

PG消除DOUBLE BUFFERING，在技術發展上來說，是必須要做的事情，只不過因為歷史欠債還是較多，這方面的改造工作量很大，需要一些時間來完成。一旦PG完成這個改造，將可以充分利用AIO的能力，大幅提升PG數據庫讀寫的能力，從而讓PG數據庫真正向大型關系型數據庫邁出一大步。目前我們有很多數據庫企業都是基于PG生態在做研發，我也希望我們的數據庫廠商能夠在這方面多投入一些研發，為PG社區解決這個難題提供一些中國方案。