本篇內(nèi)容介紹了“PostgreSQL 12 GA的新特性有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
成都創(chuàng)新互聯(lián)"三網(wǎng)合一"的企業(yè)建站思路。企業(yè)可建設(shè)擁有電腦版、微信版、手機(jī)版的企業(yè)網(wǎng)站。實(shí)現(xiàn)跨屏營(yíng)銷，產(chǎn)品發(fā)布一步更新，電腦網(wǎng)絡(luò)+移動(dòng)網(wǎng)絡(luò)一網(wǎng)打盡，滿足企業(yè)的營(yíng)銷需求！
成都創(chuàng)新互聯(lián)具備承接各種類型的網(wǎng)站制作、
做網(wǎng)站項(xiàng)目的能力。經(jīng)過十余年的努力的開拓，為不同行業(yè)的企事業(yè)單位提供了優(yōu)質(zhì)的服務(wù)，并獲得了客戶的一致好評(píng)。
SQL的執(zhí)行優(yōu)化
第一個(gè)重要的變更：重建索引的并行化處理。 比如在遇到
索引數(shù)據(jù)損壞、索引膨脹、索引的創(chuàng)建選項(xiàng)變更、無效索引重建等情況，在之前版本中，重建索引需要在表上加全局只讀鎖，阻止其他會(huì)話的寫入。而在現(xiàn)在，則通過一個(gè)細(xì)分的多步事務(wù)操作，避免了這個(gè)問題，具體如下：
1. 首先，是開啟事務(wù)，創(chuàng)建臨時(shí)索引。2. 在臨時(shí)索引上開始插入數(shù)據(jù)，這里需要注意的是，如果是重建表上的所有索引，那么這里也會(huì)同時(shí)創(chuàng)建對(duì)應(yīng)數(shù)量的臨時(shí)索引。3. 當(dāng)前一步插入數(shù)據(jù)完成，再插入創(chuàng)建索引期間產(chǎn)生的新的數(shù)據(jù)。4. 所有數(shù)據(jù)都插入完畢后，使用臨時(shí)縮影替換掉原先的索引。5. 最后刪除老索引完成整體操作。 第二個(gè)重要的變更：生成列功能的加入。 在數(shù)據(jù)庫(kù)的使用中，難免會(huì)遇到需要的數(shù)據(jù)庫(kù)表的某一列或者某幾列使用函數(shù)生成的數(shù)據(jù)。這種時(shí)候，如果每次都是實(shí)時(shí)地進(jìn)行運(yùn)算，那么這個(gè)計(jì)算代價(jià)比較大，尤其是表非常大的時(shí)候。 生成列的出現(xiàn)就是為了解決這個(gè)問題。每當(dāng)數(shù)據(jù)插入數(shù)據(jù)庫(kù)表的時(shí)候，對(duì)于生成列來說，就會(huì)生成其對(duì)應(yīng)的數(shù)據(jù)，而不需要用戶的明確輸入，當(dāng)然實(shí)際上用戶也無法輸入。 在PG的實(shí)現(xiàn)里面，包含了對(duì)生成列的索引的處理。 但是目前這個(gè)功能的實(shí)現(xiàn)也不是萬(wàn)能的，它存在很多的限制。下面我列出其中一些：
1. 目前只能實(shí)現(xiàn)某一行的計(jì)算。2. 不支持子查詢。3. 不能使用別的生成列。4. 能用作分區(qū)鍵。 第三個(gè)重要的變更：優(yōu)化器層面的處理，即CTE的inline優(yōu)化。 CTE，實(shí)際上指的就是with語(yǔ)法指定的在主SQL語(yǔ)句前面的查詢，通常會(huì)作為臨時(shí)表提供給主查詢結(jié)構(gòu)使用。 在之前的實(shí)現(xiàn)形態(tài)中，執(zhí)行時(shí)候會(huì)首先查詢出來CTE內(nèi)的數(shù)據(jù)作為臨時(shí)表，然后去對(duì)執(zhí)行主查詢對(duì)應(yīng)的操作，而在PostgreSQL 12中，這里進(jìn)行了名為
inline的優(yōu)化：如果ctw表達(dá)式指定的表，在主查詢中制備使用了一次，那么，數(shù)據(jù)庫(kù)會(huì)直接使用子查詢，而非預(yù)先查詢的方式來執(zhí)行之后的查詢與處理，這里與c等編程語(yǔ)言的inline意味類似。 通過子查詢進(jìn)行進(jìn)一步的優(yōu)化，可以很大程度地提升性能。 這個(gè)特性也可以人工控制，對(duì)于一些不滿足條件的CTE也進(jìn)行inline處理（MATERIALIZED），或者對(duì)滿足條件的情況下，依然不使用inline方式處理（NOT MATERIALIZED）。
第四個(gè)重要的變更：緩存執(zhí)行計(jì)劃，目前雖然未見得有多么重要，但在未來，可能會(huì)有很大作用的一個(gè)功能。 眾所周知，Oracle是緩存執(zhí)行計(jì)劃的，而類似MySQL，PostgreSQL這些開源數(shù)據(jù)庫(kù)，都是SQL語(yǔ)句每次現(xiàn)場(chǎng)解析來處理的。而現(xiàn)在，PostgreSQL 12中，首先做到了執(zhí)行計(jì)劃的緩存———雖然這個(gè)功能影響范圍目前十分有限：目前只有明確使用了prepare語(yǔ)句，創(chuàng)建了臨時(shí)過程，或者干脆就是存儲(chǔ)過程PL/pgSQL，否則無法使用到緩存的執(zhí)行計(jì)劃，遠(yuǎn)遠(yuǎn)達(dá)不到像Oracle那樣，普通SQL語(yǔ)句都可以緩存執(zhí)行計(jì)劃。 但是，可以展望的未來，就勢(shì)必會(huì)有這么一個(gè)優(yōu)化。而這，也將是后續(xù)PG的迭代版本需要去做到的事情。
第五個(gè)重要的變更：實(shí)際上是配置的變更，但其主題影響的是SQL執(zhí)行，因此在這里簡(jiǎn)單說一下，就是JIT在PostgreSQL 12中，默認(rèn)是打開的狀態(tài)。 關(guān)于
JIT，在這里簡(jiǎn)單描述一下：把SQL語(yǔ)句中的簡(jiǎn)單計(jì)算，直接編譯為機(jī)器匯編碼執(zhí)行，效率遠(yuǎn)高于需要從SQL轉(zhuǎn)C調(diào)用的普通SQL執(zhí)行效率，除了需要在SQL解析階段稍微多一點(diǎn)CPU之外，沒有其他壞處，而打開這個(gè)特性，獲得的好處是巨大的。
配置的優(yōu)化
除了SQL優(yōu)化這個(gè)開發(fā)人員最關(guān)心的話題之外，對(duì)于運(yùn)維來說，PG 12這個(gè)版本也做到很多的變化。
第一個(gè)，是新增了兩個(gè)管理用的視圖，以及一個(gè)新的函數(shù)：- pg_stat_progress_create_index 查看當(dāng)前正在創(chuàng)建的索引進(jìn)度- pg_stat_progress_cluster 查看當(dāng)前vacuum full/cluster進(jìn)度- pg_ls_archive_statusdir() 列出歸檔狀態(tài)文件夾內(nèi)容 這個(gè)變化讓DBA可以對(duì)數(shù)據(jù)庫(kù)中發(fā)生的重度行為有更詳細(xì)的了解，以下定更好的決策。
第二個(gè)，是我認(rèn)為絕對(duì)值得大書一筆，在PG歷史上留下精彩篇章的變更：“干掉”recovery.conf文件，配置項(xiàng)目合并入postgresql.conf配置文件。 這個(gè)文件幾乎伴隨著PG的出現(xiàn)就已經(jīng)存在了，在PG 9.0版本之前漫長(zhǎng)的年代，這個(gè)文件負(fù)責(zé)了redo（WAL/XLOG）的回放配置，因此叫做
recovery.conf。在9.0之后，流復(fù)制出現(xiàn)，于是理所當(dāng)然地，流復(fù)制的配置，也被放到這個(gè)文件里面了。而后，實(shí)際上這個(gè)文件更多地扮演者流復(fù)制配置而非數(shù)據(jù)恢復(fù)的角色。但是，與數(shù)據(jù)恢復(fù)僅僅需要離線操作不同，流復(fù)制在很多時(shí)候，是需要有在線變更手段的，而recovery.conf不支持reload，就成了一個(gè)需要解決的麻煩事了。 在PostgreSQL開始，這個(gè)文件原先的項(xiàng)目合并到postgresql.conf之后，為了避免配置沖突，PG自己新增了一個(gè)強(qiáng)行的限制：如果檢查到數(shù)據(jù)目錄有recovery.conf這個(gè)文件，則不允許數(shù)據(jù)庫(kù)啟動(dòng)。 這個(gè)合并，不僅僅是個(gè)單純的合并，也牽扯到很多相關(guān)參數(shù)的改名以及默認(rèn)值變更：
- 以下參數(shù)允許reloadarchive_cleanup_command
promote_trigger_file
recovery_end_command
recovery_min_apply_delay
- 名稱與默認(rèn)值變更trigger_file 名稱變更為promote_trigger_file
取消standby_mode 配置選項(xiàng)
不允許指定多個(gè)recovery target
默認(rèn)恢復(fù)到last時(shí)間線（之前是current）
使用cluster name作為默認(rèn)的wal receiver的application name
相信未來的后續(xù)版本，PG主從切換之后，standby不需要重啟就可以變更主庫(kù)，也不是一件不可能的事情了。
第三個(gè)，是PG的日常問題，vacuum的優(yōu)化： 這些設(shè)置當(dāng)然可以極大程度地減小vacuum對(duì)數(shù)據(jù)庫(kù)的影響，但對(duì)PG的未來來說，更好地解決這個(gè)問題的方式，當(dāng)然是新的存儲(chǔ)引擎。
獨(dú)立存儲(chǔ)引擎
就實(shí)際來說，MySQL早些年的MyISAM，實(shí)現(xiàn)質(zhì)量并不好，不支持事務(wù)，表級(jí)別的讀寫鎖。但因?yàn)榇鎯?chǔ)引擎獨(dú)立接口，MySQL等到了InnoDB，InnoDB實(shí)現(xiàn)了全套事務(wù)存儲(chǔ)引擎，且現(xiàn)在已完全取代了MyISAM的地位。 而PG本身就實(shí)現(xiàn)了事務(wù)存儲(chǔ)引擎，這個(gè)獨(dú)立存儲(chǔ)引擎的需求雖然很多年前早已規(guī)劃，但實(shí)際上拆分出來正經(jīng)去做，才是這個(gè)迭代的事情。 目前，PG單獨(dú)處理了數(shù)據(jù)存儲(chǔ)，索引存儲(chǔ)的接口，第三方可以直接實(shí)現(xiàn)對(duì)應(yīng)的接口和數(shù)據(jù)結(jié)構(gòu)，就可以讓PG利用到新增的存儲(chǔ)引擎。 在社區(qū)里，已經(jīng)有兩個(gè)非常重要的存儲(chǔ)引擎產(chǎn)生--雖然距離生成環(huán)境尚且還有一段距離，但這兩個(gè)存儲(chǔ)引擎都解決了PG本身存在多年的痼疾，未來可期。 兩個(gè)非常重要的存儲(chǔ)引擎，就是EDB的
zheap（開發(fā)中），以及Greenplum團(tuán)隊(duì)共享的
zedstore（開發(fā)中）存儲(chǔ)引擎。
首先，說一說zheap。 PostgreSQL的存儲(chǔ)實(shí)現(xiàn)中，其中dirty的一部分，vacuum，在實(shí)際生產(chǎn)環(huán)境中，成了一個(gè)每個(gè)運(yùn)維都必須面對(duì)的問題。在zheap中，通過引入undo日志，zheap試圖同時(shí)解決vacuum問題，以及32位事務(wù)id導(dǎo)致的vacuum freeze（事務(wù)ID回卷）問題。 在zheap中，并沒有對(duì)heap（后文以此代稱“pg”原生存儲(chǔ)引擎）的索引，執(zhí)行計(jì)劃等進(jìn)行處理，而只是單純處理了其數(shù)據(jù)存儲(chǔ)部分，也就是把undo從數(shù)據(jù)文件剝離出來成為undo日志。 目前其實(shí)現(xiàn)是：undo日志一直向前寫（類似WAL日志），單獨(dú)的purge進(jìn)程從undo日志最老的日志開始回收，數(shù)據(jù)變更會(huì)保留在undo日志的數(shù)據(jù)指針，方便需要查詢“老”數(shù)據(jù)的情況。這么一來，就可以避免數(shù)據(jù)文件的膨脹，以及vacuum的全表掃描的代價(jià)了。
而zedstore則代表了不同的方向：OLAP。greenplum所處理的，就是MPP數(shù)據(jù)倉(cāng)庫(kù)，而在數(shù)據(jù)倉(cāng)庫(kù)來說，通常掃描一個(gè)表特定幾列的情況，會(huì)遠(yuǎn)多于需要同時(shí)掃所有列的情況，因此zedstore設(shè)計(jì)目的，就是一個(gè)列存數(shù)據(jù)庫(kù)。 zedstore的實(shí)現(xiàn)中，每個(gè)條目，都有一個(gè)名為tid的虛擬主鍵，表的某一列或者某幾列，就保存在使用tid作為主鍵的B樹索引中。通過支持tid到多列的索引，也相當(dāng)于實(shí)現(xiàn)了“行列混合存儲(chǔ)”。 zedstore另外一個(gè)重要的實(shí)現(xiàn)，就是壓縮。zedstore數(shù)據(jù)存儲(chǔ)的時(shí)候，是只壓縮數(shù)據(jù)，不壓縮數(shù)據(jù)塊元數(shù)據(jù)的，這么搞雖然犧牲了一定比例的壓縮比（考慮到數(shù)據(jù)塊頭的大小，未必有多大代價(jià)）。但得到的好處就是顯而易見了：數(shù)據(jù)塊以壓縮的形態(tài)存儲(chǔ)在共享池中，由用戶會(huì)話解壓縮各自所需的數(shù)據(jù)--作為對(duì)比的MySQL InnoDB壓縮，就是整個(gè)數(shù)據(jù)塊級(jí)別的壓縮，于是共享池里面，就得同時(shí)保存數(shù)據(jù)塊的壓縮與未壓縮版本，平白消耗了寶貴的內(nèi)存。
“PostgreSQL 12 GA的新特性有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
網(wǎng)站名稱：PostgreSQL12GA的新特性有哪些-創(chuàng)新互聯(lián)
新聞來源：
http://weahome.cn/article/ihisj.html
重慶分公司
重慶分公司
