PG 16的第一個預覽版發(fā)布了，也就是說PG社區(qū)已經(jīng)鎖定了PG 16的基本功能，到正式版發(fā)布雖然還有一段時間，不過在正式版里，剪掉某些功能是有可能的，增加某些功能基本上是無望了。很多PGer對于PG 16的功能更新有些失望，這次的失望恐怕要高于PG15。PGer最大的失望莫過于XID 64、內(nèi)置連接池等重要功能的缺席。我也看到了網(wǎng)上一些朋友對PG16擠牙膏似的功能更新感到無力吐槽。事實是否如此呢？今天老白以自己的觀點來給大家解析一下PG16更新的Highlight。

16個“亮眼”的新功能Highlight的第一個就是性能方面的，首先是并行查詢方面的性能提升。實際上如果仔細研究一下這些文字，里面包含的信息還是挺豐富的。在并行執(zhí)行方面，PG這些年還是下了很大功夫的，在近期的每個版本中都會出現(xiàn)一些和并行執(zhí)行相關的新特性。這說明PG核心研發(fā)團隊對于硬件技術的提升還是跟隨得很緊的，希望利用現(xiàn)代硬件的新特性來為PG的性能做加持。

PostgreSQL 16增加了更多的并行查詢能力，比如允許FULL和RIGHT JION在并行模式下執(zhí)行，這兩類都是SQL中常有的操作，可以對十分廣泛的SQL執(zhí)行加速。允許parallel group和parallel aggregate則會對統(tǒng)計類的SQL加速，從而更快的執(zhí)行一些大數(shù)據(jù)量分析的SQL。

另外一個性能方面的提升中的“增量排序”是指在排序時，可以先對一部分數(shù)據(jù)進行排序，然后逐步加入更多的數(shù)據(jù)，而不是一次性對所有數(shù)據(jù)進行排序，從而節(jié)省內(nèi)存和時間。PostgreSQL 16可以在SELECT DISTINCT 查詢中使用增量排序，從而提高查詢的性能。

“窗口查詢”是指在執(zhí)行一個select查詢時，可以對結果集中的每一行或每一組行應用一些聚合函數(shù)或分析函數(shù)，比如求和、平均、排名等。PostgreSQL 16對窗口查詢進行了一些優(yōu)化，比如支持使用frame clause來指定窗口范圍，支持在此類SQL中，對RANGE和LIST分區(qū)使用push down predicate來過濾不需要的數(shù)據(jù)，支持使用partition pruning來跳過不相關的分區(qū)等，并且支持在右外連接條件中使用“anti join”。

PG 16的并行執(zhí)行并不僅僅限于SELECT，對于BULK LOADING操作也支持并發(fā)模式，這個改進可以將COPY命令的性能提升3倍。大數(shù)據(jù)量裝載在數(shù)據(jù)庫遷移和ETL等操作中都十分常見，3倍的性能提升還是挺令人滿意的。

This release also introduces support for CPU acceleration using SIMD for both x86 and ARM architectures, including optimizations for processing ASCII and JSON strings, and array and subtransaction searches. Additionally, PostgreSQL 16 introduces load balancing to libpq, the client lib。

上面這句話包含了兩方面的內(nèi)容，一方面是PG16對SIMD的支持，一方面是libpq支持LOAD BALANCE了。不知道為什么要把這兩件事放在一段里，目前還沒有測試過，所以也不清楚二者是否有關。不過這意味著libpq可以自動選擇最佳的服務器來處理客戶端的請求，從而提高性能和可靠性。另外這個功能也意味著今后PG數(shù)據(jù)庫的高可用與讀寫分離將會有更加簡單的實現(xiàn)，這也為某些以讀為主的應用提供了一種更加簡單的實現(xiàn)方式。

上面那句話的另外一面是關于SIMD的，PG 16支持SIMD了。這是一件大事嗎？對PG來說也許是的，不過SIMD已經(jīng)不是啥新鮮玩意了，如果早上幾年，這也許算是一個創(chuàng)新。Oracle 12c的IMDB就已經(jīng)開始使用SIMD來做行列轉換了,Clickhouse等數(shù)據(jù)庫也早就用上了，國產(chǎn)數(shù)據(jù)庫也大量使用SIMD，比如openGauss前些年就在宣傳對SIMD的支持了。SIMD 是一種 CPU 的加速技術，可以充分利用CPU指令集的特性，比如INTEL的AVX-512指令集的能力實現(xiàn)超寬向量操作，讓 CPU 一次處理多個數(shù)據(jù)，從而提高運算速度。PostgreSQL 16針對X86和ARM CPU 支持使用 SIMD 技術來加速一些常見的操作，比如處理 ASCII 和 JSON 字符串。

針對這個特性，放在2023年的今天還放在HIGHLIGHT里作為一個亮點來介紹，似乎有點大驚小怪了，好像當年Oracle 12c的新特性里壓根就放不下這一條。倒是一些國產(chǎn)數(shù)據(jù)庫只要用上一點SIMD就號稱在數(shù)據(jù)庫中支持矢量計算了。

 在邏輯復制上，PG16也發(fā)布了一些新特性，其中最重要的是可以將邏輯復制的解碼工作從主庫下載到從庫，這可以大大減輕主庫的工作壓力，在高負載情況下提高主庫的性能。另外在對大事務的復制優(yōu)化上，PG16支持對大事務進行并行APPLY，從而解決大事務導致邏輯復制延時過大的問題。另外一個性能優(yōu)化是，在邏輯復制UPDATE/DELETE操作時，不僅僅可以使用主鍵，也可以使用其他索引。上述關于邏輯復制的性能優(yōu)化，算是中規(guī)中矩，從庫解碼和大事務并行APPLY都是十分有價值的更新。

今天時間有限，關于開發(fā)體驗和安全的新特性我們先跳過，我們直接來看下一條：監(jiān)控與管理。這是DBA最為關心的內(nèi)容。其中最令DBA興奮的是pg_stat_io。DBA苦無法獲知PG的IO性能指標久矣。在D-SMART里，PG數(shù)據(jù)庫的健康模型中冠以PGIO的指標十分稀缺。

可以看到，在D-SMART的健康模型中，關于PG IO方面的指標只有區(qū)區(qū)數(shù)個，而且還都是參考性不夠強的指標。

在同門兄弟openGauss中，指標的數(shù)量與質量都有了明顯的提高，我們的健康模型也更能夠反映出數(shù)據(jù)庫的IO負載與性能狀態(tài)。在PG16中，這些問題得到了改善，pg_stat_io可以按照backend類型對IO進行統(tǒng)計，包括讀寫次數(shù)，讀寫時間，回寫次數(shù)等信息。

對于失望于沒有看到XID64的朋友，PG16給了大家一個安慰獎：“This release includes improvements to the page freezing strategy, which helps the performance of vacuuming and other maintenance operations.”?？赡苁怯悬c不好意思吧，在新特性中僅僅提了上面一句話。PostgreSQL 16通過使用主動的時間線來驅動 VACUUM 凍結，從而避免不必要的凍結元組。這樣可以減少自動清理的頻率，并提高清理效率。

關于這個問題，大家意見比較大是可以理解的，不過我們也要理解修改XID的難處。以Oracle為例，在2002年左右爆發(fā)的SCN HEADROOM問題一些老DBA可能還記得，這是因為48位的SCN以及40年前的設計者為了讓Oracle數(shù)據(jù)庫能保用500年而設計的每秒SCN增長16K的天花板。哪怕是剛剛出現(xiàn)問題的2002年，每秒新增1.6萬事務的估計顯得有點科幻，不過隨著硬件能力的提升，現(xiàn)在一秒鐘干20萬筆事務的數(shù)據(jù)庫系統(tǒng)已經(jīng)很常見了。二十年前問題剛剛爆發(fā)時，Oracle官方就認為徹底解決該問題的方法是將48位的SCN升級為64位。不過20年過去了，Oracle還沒有實現(xiàn)這個升級，而是把數(shù)據(jù)庫SCN必須你能夠保用500年這一條改掉了，誰家的數(shù)據(jù)庫能一庫到底500年？讓SCN HEADROOM突破16K的限制比把SCN改成64位簡單多了。我想目前PG社區(qū)的老大們目前也在往這方面想吧。

今天因為時間問題，我就寫這么多吧，一些其他的特性就不做詳細的解讀了。目前我也僅僅是解讀了文檔，并沒有真正的去使用PG16，有些東西是不是我想象的這樣，這就需要今后實踐中去體驗了。從對PG16新特性的解析上看，雖然說對于一個年度更新大版本的數(shù)據(jù)庫產(chǎn)品來說，這些提升還是說得過去的，不過也看出了PG社區(qū)的大佬們還是偏于保守，不過對于數(shù)據(jù)庫產(chǎn)品來說，穩(wěn)定是第一位的，確保數(shù)據(jù)安全的優(yōu)先級是遠高于創(chuàng)新的，所以大家也不要太失望。