PostgreSQL 12 GA的新特性有哪些

發布時間：2021-11-08 14:17:56 來源：億速云閱讀：165 作者：iii 欄目：關系型數據庫

本篇內容介紹了“PostgreSQL 12 GA的新特性有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

SQL的執行優化

第一個重要的變更：重建索引的并行化處理。

比如在遇到索引數據損壞、索引膨脹、索引的創建選項變更、無效索引重建等情況，在之前版本中，重建索引需要在表上加全局只讀鎖，阻止其他會話的寫入。而在現在，則通過一個細分的多步事務操作，避免了這個問題，具體如下：

1. 首先，是開啟事務，創建臨時索引。

2. 在臨時索引上開始插入數據，這里需要注意的是，如果是重建表上的所有索引，那么這里也會同時創建對應數量的臨時索引。

3. 當前一步插入數據完成，再插入創建索引期間產生的新的數據。

4. 所有數據都插入完畢后，使用臨時縮影替換掉原先的索引。

5. 最后刪除老索引完成整體操作。

第二個重要的變更：生成列功能的加入。

在數據庫的使用中，難免會遇到需要的數據庫表的某一列或者某幾列使用函數生成的數據。這種時候，如果每次都是實時地進行運算，那么這個計算代價比較大，尤其是表非常大的時候。

生成列的出現就是為了解決這個問題。每當數據插入數據庫表的時候，對于生成列來說，就會生成其對應的數據，而不需要用戶的明確輸入，當然實際上用戶也無法輸入。

在PG的實現里面，包含了對生成列的索引的處理。

但是目前這個功能的實現也不是萬能的，它存在很多的限制。下面我列出其中一些：

1. 目前只能實現某一行的計算。

2. 不支持子查詢。

3. 不能使用別的生成列。

4. 能用作分區鍵。

第三個重要的變更：優化器層面的處理，即CTE的inline優化。

CTE，實際上指的就是with語法指定的在主SQL語句前面的查詢，通常會作為臨時表提供給主查詢結構使用。

在之前的實現形態中，執行時候會首先查詢出來CTE內的數據作為臨時表，然后去對執行主查詢對應的操作，而在PostgreSQL 12中，這里進行了名為inline的優化：

如果ctw表達式指定的表，在主查詢中制備使用了一次，那么，數據庫會直接使用子查詢，而非預先查詢的方式來執行之后的查詢與處理，這里與c等編程語言的inline意味類似。

通過子查詢進行進一步的優化，可以很大程度地提升性能。

這個特性也可以人工控制，對于一些不滿足條件的CTE也進行inline處理（MATERIALIZED），或者對滿足條件的情況下，依然不使用inline方式處理（NOT MATERIALIZED）。

第四個重要的變更：緩存執行計劃，目前雖然未見得有多么重要，但在未來，可能會有很大作用的一個功能。

眾所周知，Oracle是緩存執行計劃的，而類似MySQL，PostgreSQL這些開源數據庫，都是SQL語句每次現場解析來處理的。而現在，PostgreSQL 12中，首先做到了執行計劃的緩存———雖然這個功能影響范圍目前十分有限：

目前只有明確使用了prepare語句，創建了臨時過程，或者干脆就是存儲過程PL/pgSQL，否則無法使用到緩存的執行計劃，遠遠達不到像Oracle那樣，普通SQL語句都可以緩存執行計劃。

但是，可以展望的未來，就勢必會有這么一個優化。而這，也將是后續PG的迭代版本需要去做到的事情。

第五個重要的變更：實際上是配置的變更，但其主題影響的是SQL執行，因此在這里簡單說一下，就是JIT在PostgreSQL 12中，默認是打開的狀態。

關于JIT，在這里簡單描述一下：把SQL語句中的簡單計算，直接編譯為機器匯編碼執行，效率遠高于需要從SQL轉C調用的普通SQL執行效率，除了需要在SQL解析階段稍微多一點CPU之外，沒有其他壞處，而打開這個特性，獲得的好處是巨大的。

配置的優化

除了SQL優化這個開發人員最關心的話題之外，對于運維來說，PG 12這個版本也做到很多的變化。

第一個，是新增了兩個管理用的視圖，以及一個新的函數：

- pg_stat_progress_create_index 查看當前正在創建的索引進度

已經執行的數據塊數量
已經執行的行數量
使用/等待鎖的情況

- pg_stat_progress_cluster 查看當前vacuum full/cluster進度

數據塊讀寫數量

數據條目讀寫數量

- pg_ls_archive_statusdir() 列出歸檔狀態文件夾內容

這個變化讓DBA可以對數據庫中發生的重度行為有更詳細的了解，以下定更好的決策。

第二個，是我認為絕對值得大書一筆，在PG歷史上留下精彩篇章的變更：“干掉”recovery.conf文件，配置項目合并入postgresql.conf配置文件。

這個文件幾乎伴隨著PG的出現就已經存在了，在PG 9.0版本之前漫長的年代，這個文件負責了redo（WAL/XLOG）的回放配置，因此叫做recovery.conf。在9.0之后，流復制出現，于是理所當然地，流復制的配置，也被放到這個文件里面了。而后，實際上這個文件更多地扮演者流復制配置而非數據恢復的角色。但是，與數據恢復僅僅需要離線操作不同，流復制在很多時候，是需要有在線變更手段的，而recovery.conf不支持reload，就成了一個需要解決的麻煩事了。

在PostgreSQL開始，這個文件原先的項目合并到postgresql.conf之后，為了避免配置沖突，PG自己新增了一個強行的限制：如果檢查到數據目錄有recovery.conf這個文件，則不允許數據庫啟動。

這個合并，不僅僅是個單純的合并，也牽扯到很多相關參數的改名以及默認值變更：

- 以下參數允許reload

archive_cleanup_command
promote_trigger_file
recovery_end_command
recovery_min_apply_delay

- 名稱與默認值變更

trigger_file 名稱變更為promote_trigger_file
取消standby_mode 配置選項
不允許指定多個recovery target
默認恢復到last時間線（之前是current）
使用cluster name作為默認的wal receiver的application name

相信未來的后續版本，PG主從切換之后，standby不需要重啟就可以變更主庫，也不是一件不可能的事情了。

第三個，是PG的日常問題，vacuum的優化：

設置VACUUM不回收尾部空白頁

設置VACUUM跳過對索引的掃描

設置VACUUM遇到無法立即獲取的鎖則跳過

這些設置當然可以極大程度地減小vacuum對數據庫的影響，但對PG的未來來說，更好地解決這個問題的方式，當然是新的存儲引擎。

獨立存儲引擎

就實際來說，MySQL早些年的MyISAM，實現質量并不好，不支持事務，表級別的讀寫鎖。但因為存儲引擎獨立接口，MySQL等到了InnoDB，InnoDB實現了全套事務存儲引擎，且現在已完全取代了MyISAM的地位。

而PG本身就實現了事務存儲引擎，這個獨立存儲引擎的需求雖然很多年前早已規劃，但實際上拆分出來正經去做，才是這個迭代的事情。

目前，PG單獨處理了數據存儲，索引存儲的接口，第三方可以直接實現對應的接口和數據結構，就可以讓PG利用到新增的存儲引擎。

在社區里，已經有兩個非常重要的存儲引擎產生--雖然距離生成環境尚且還有一段距離，但這兩個存儲引擎都解決了PG本身存在多年的痼疾，未來可期。

兩個非常重要的存儲引擎，就是EDB的zheap（開發中），以及Greenplum團隊共享的zedstore（開發中）存儲引擎。

首先，說一說zheap。

PostgreSQL的存儲實現中，其中dirty的一部分，vacuum，在實際生產環境中，成了一個每個運維都必須面對的問題。在zheap中，通過引入undo日志，zheap試圖同時解決vacuum問題，以及32位事務id導致的vacuum freeze（事務ID回卷）問題。

在zheap中，并沒有對heap（后文以此代稱“pg”原生存儲引擎）的索引，執行計劃等進行處理，而只是單純處理了其數據存儲部分，也就是把undo從數據文件剝離出來成為undo日志。

目前其實現是：undo日志一直向前寫（類似WAL日志），單獨的purge進程從undo日志最老的日志開始回收，數據變更會保留在undo日志的數據指針，方便需要查詢“老”數據的情況。這么一來，就可以避免數據文件的膨脹，以及vacuum的全表掃描的代價了。

而zedstore則代表了不同的方向：OLAP。

greenplum所處理的，就是MPP數據倉庫，而在數據倉庫來說，通常掃描一個表特定幾列的情況，會遠多于需要同時掃所有列的情況，因此zedstore設計目的，就是一個列存數據庫。

zedstore的實現中，每個條目，都有一個名為tid的虛擬主鍵，表的某一列或者某幾列，就保存在使用tid作為主鍵的B樹索引中。通過支持tid到多列的索引，也相當于實現了“行列混合存儲”。

zedstore另外一個重要的實現，就是壓縮。zedstore數據存儲的時候，是只壓縮數據，不壓縮數據塊元數據的，這么搞雖然犧牲了一定比例的壓縮比（考慮到數據塊頭的大小，未必有多大代價）。但得到的好處就是顯而易見了：數據塊以壓縮的形態存儲在共享池中，由用戶會話解壓縮各自所需的數據--作為對比的MySQL InnoDB壓縮，就是整個數據塊級別的壓縮，于是共享池里面，就得同時保存數據塊的壓縮與未壓縮版本，平白消耗了寶貴的內存。

“PostgreSQL 12 GA的新特性有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！

向AI問一下細節

91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

PostgreSQL 12 GA的新特性有哪些

配置的優化

獨立存儲引擎

猜你喜歡

91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

PostgreSQL 12 GA的新特性有哪些

配置的優化

獨立存儲引擎

猜你喜歡

最新資訊

相關推薦

相關標簽