PostgreSQL 19 來啦，有哪些高價(jià)值特性值得關(guān)注？

　　4月21日，「YOLANDA 科技見聞」獨(dú)家聯(lián)動(dòng) HOW 2026(開源生態(tài)大會(huì)暨 PostgreSQL 高峰論壇)推出一期特別直播。墨創(chuàng)數(shù)跡創(chuàng)始人汪丹(Yolanda)主持，專訪了三位 HOW 2026 大會(huì)出品人及演講嘉賓：IvorySQL專家顧問委員、PostgreSQL ACED、前阿里云數(shù)據(jù)庫高級(jí)專家德哥，云和恩墨高級(jí)數(shù)據(jù)庫技術(shù)顧問、IvorySQL 專家顧問委員彭沖，PostgreSQL ACE、PG分會(huì)西安用戶組主席、公眾號(hào)【PostgreSQL 運(yùn)維之道】主理人楊向博，共同探討了 PostgreSQL 18 的好用“真香”特性，前瞻解讀 PostgreSQL 19 的新能力，還為企業(yè)版本升級(jí)策略提供參考思路，并分享了專家們參與 PG 社區(qū)的實(shí)踐與經(jīng)驗(yàn)，干貨滿滿。

　　劃重點(diǎn)：

　　1.PG 的每一次大版本發(fā)布，都是令人驚喜的。它不是簡(jiǎn)單的修修補(bǔ)補(bǔ)，而是有很多亮眼的新特性，真實(shí)解決了很多痛點(diǎn)問題。

　　2.PG 的進(jìn)化不是激進(jìn)的，而是務(wù)實(shí)的。社區(qū)的嚴(yán)苛性保證了穩(wěn)定性，插件生態(tài)驗(yàn)證了需求，內(nèi)核化完成了收斂。這是 PG 獨(dú)特的進(jìn)化路徑。

　　3.PG 不會(huì)為了追求新特性而犧牲穩(wěn)定性，也不會(huì)因?yàn)楸Ｊ囟�拒絕變化。其豐富插件的可擴(kuò)展性優(yōu)勢(shì)，讓很多東西可以像搭積木一樣實(shí)現(xiàn)。

　　4.從 PG 18 的異步 I/O 支持、統(tǒng)計(jì)信息保留，到 PG 19 的 REPACK 內(nèi)核化、圖查詢引入，我們看到了未來數(shù)據(jù)庫的更多可能性。

　　5.企業(yè)什么時(shí)候應(yīng)該升級(jí)新版本?沒有最好的版本，只有最合適的版本。不為升級(jí)而升級(jí)，只為解決真問題。

　　6.PG 社區(qū)開放包容，社區(qū)貢獻(xiàn)沒有標(biāo)準(zhǔn)答案。從報(bào) Bug 到寫插件，從文章分享到內(nèi)核提交，每一個(gè)聲音都能成為PG進(jìn)化的一部分。從小處著手，向內(nèi)核生長(zhǎng)。

　　PostgreSQL 18 回顧：4 個(gè)“真香”特性

　　01 支持異步I/O

　　讓德哥覺得“真香”的第一個(gè)能力是 PG 18 支持了異步I/O。

　　現(xiàn)在很多數(shù)據(jù)庫是跑在云上的，云上數(shù)據(jù)庫和線下部署完全是兩回事。在本地部署中，數(shù)據(jù)庫直接訪問 SSD，I/O 延遲通常在微秒級(jí)別。但云上存儲(chǔ)會(huì)用云盤，云盤底層要通過網(wǎng)絡(luò)去訪問，網(wǎng)絡(luò)延遲相較于本地部署會(huì)高很多。像創(chuàng)建索引、垃圾回收、大表掃描、分析型查詢等大 I/O 訪問量操作，在 PG 18 之前都使用同步 I/O，數(shù)據(jù)庫進(jìn)程的大量時(shí)間都耗費(fèi)在網(wǎng)絡(luò)等待上。PG 18 支持異步 I/O 子系統(tǒng)改變了這個(gè)局面，這些大 I/O 訪問操作的性能提升立竿見影。

　　02 保留統(tǒng)計(jì)信息

　　德哥分享的第二個(gè)特性和大版本升級(jí)有關(guān)，可能應(yīng)用不多，但非常有價(jià)值，比如云廠商就會(huì)比較激進(jìn)地提供大版本升級(jí)能力。一般來說，大版本升級(jí)有兩種方式，一種是通過邏輯復(fù)制，復(fù)制后做切換，不過這種方式有比較嚴(yán)苛的適應(yīng)場(chǎng)景，要求所有表都要有主鍵，同步過程中一些不可抗因素也會(huì)導(dǎo)致切換后數(shù)據(jù)不一致。

　　另外一種是通過 pg_upgrade 直接導(dǎo)出元數(shù)據(jù)，然后在大版本上面導(dǎo)入新的元數(shù)據(jù)，這種方式被詬病的地方就是統(tǒng)計(jì)信息導(dǎo)不過去，如果升級(jí)之后立馬開放給用戶使用，執(zhí)行計(jì)劃就可能不準(zhǔn)確。特別是如果遇到業(yè)務(wù)高峰，或者有一些亂查詢，由于沒有統(tǒng)計(jì)信息往往導(dǎo)致執(zhí)行計(jì)劃不準(zhǔn)，這種請(qǐng)求多起來的話，很可能帶來雪崩效應(yīng)。PG 18 引入了保留統(tǒng)計(jì)信息的能力，徹底解決了這個(gè)問題。執(zhí)行計(jì)劃不會(huì)因?yàn)樯��?jí)而退化，避免了“升級(jí)即事故”的風(fēng)險(xiǎn)，這對(duì)于無法承受長(zhǎng)時(shí)間維護(hù)窗口的企業(yè)級(jí)應(yīng)用來說，是一個(gè)質(zhì)的飛躍。

　　03

　　向博分享了一個(gè)可能會(huì)被大家忽略掉、但站在 DBA 角度看非常有用的特性。具體來說，就是 SQL 執(zhí)行計(jì)劃會(huì)跑偏，這是一個(gè)讓 DBA 很頭疼的問題。怎么辦呢?對(duì)于一些可以改 SQL 的業(yè)務(wù)來說，可以走邏輯優(yōu)化的路徑。但對(duì)于很多 SaaS 業(yè)務(wù)，定制化 SQL 改不了，一般就用 hint 提示的手段去做執(zhí)行計(jì)劃的修正。

　　可能會(huì)遇到這樣的場(chǎng)景：當(dāng)你指定一個(gè)表走更優(yōu)的索引時(shí)，有時(shí)會(huì)發(fā)現(xiàn)它不但沒走索引，反而走了順序掃描。這個(gè)路徑是怎么被選出來的?PG 17 及以前版本通過disable_cost給一個(gè)路徑的啟動(dòng)代價(jià)加上一個(gè) 100 億的常量值，以此來干預(yù)路徑選擇，方式“粗暴且不優(yōu)雅”，當(dāng)多個(gè)路徑都被加上這個(gè)巨大的常量后，原本差距明顯的路徑可能只相差 1%，它們之間的相對(duì)差異反而變得模糊，可能導(dǎo)致干預(yù)失效，最終選錯(cuò)了路徑。

　　PG 18 完全去掉了disable_cost這個(gè)歷史包袱，把它轉(zhuǎn)化成disabled_nodes，一個(gè) int 值，默認(rèn)為 0.當(dāng)你禁用一個(gè)設(shè)置時(shí)，對(duì)應(yīng)路徑的 node 值加 1.并且這個(gè)值會(huì)層層向上傳遞。這樣，就可以精確地比較不同路徑的干預(yù)程度，而不是依賴模糊的代價(jià)估算，能更精準(zhǔn)地控制執(zhí)行計(jì)劃。

　　04

　　彭沖補(bǔ)充了一個(gè)和執(zhí)行計(jì)劃相關(guān)的特性，這是 PG 18 引入的一個(gè)擴(kuò)展功能，pg_overexplain，以一種更結(jié)構(gòu)化、更精準(zhǔn)的方式，輸出深藏在內(nèi)核數(shù)據(jù)結(jié)構(gòu)中的信息，用來深度剖析優(yōu)化器的內(nèi)部決策過程，做一些內(nèi)核相關(guān)的優(yōu)化，可以幫助診斷執(zhí)行計(jì)劃。

　　PostgreSQL 19 前瞻：值得期待的更新

　　對(duì)于 PG19.德哥一直在跟進(jìn)它的 Git 提交記錄，從 2600 多個(gè) Commits 中篩選了好幾道，最開始篩出來 100 多個(gè)，覺得都特別有價(jià)值，德哥重點(diǎn)分享了幾個(gè)對(duì)他來說沖擊比較大的新能力。

　　01 引入

　　使用 PG 的一個(gè)痛點(diǎn)就是它的事務(wù) ID 只有 32 位，容易用完，所以必須不斷地做“凍結(jié)”操作。另外就是 PG 的存儲(chǔ)引擎，沒有 Undo 回滾段，所有垃圾都放在數(shù)據(jù)文件里，和正常的數(shù)據(jù)放在一起，就要不斷地做垃圾回收。一旦表膨脹了就會(huì)很麻煩，特別是在云服務(wù)里，存儲(chǔ)都得額外算錢，那每月的賬單就要滴血，壓縮膨脹空間就很關(guān)鍵。怎么辦?原來是通過第三方的pg_repack插件來解決，PG 19 把REPACK CONCURRENTLY做到內(nèi)核里來了。以后我們就可以很放心地使用REPACK CONCURRENTLY了，不用擔(dān)心第三方工具的兼容和維護(hù)等問題，這是一個(gè)極大的利好。

　　02 實(shí)現(xiàn)“圖查詢”

　　AI 時(shí)代，圖查詢是一個(gè)非常重要的特性。比如我們使用 Agent 的時(shí)候，使用越多，它堆積的記憶就越多，包括 Agent 去連接各種外部知識(shí)庫，這些數(shù)據(jù)也非常復(fù)雜。以前 PG 只能提供一些向量搜索、關(guān)鍵詞搜索、全文檢索，但實(shí)際上來看，知識(shí)很多時(shí)候是樹狀結(jié)構(gòu)的，也就是圖結(jié)構(gòu)。這時(shí)候，很多企業(yè)可能會(huì)選擇額外再搭一套圖數(shù)據(jù)庫，就會(huì)導(dǎo)致一些數(shù)據(jù)可能是重復(fù)的，浪費(fèi)企業(yè)資源。

　　PG 19 終于把圖查詢的功能引進(jìn)來了，在 AI 場(chǎng)景存儲(chǔ)記憶、存儲(chǔ)外部知識(shí)庫，這是一個(gè)很有必要的、很高級(jí)功能。德哥相信，將來的 AI 應(yīng)用在使用數(shù)據(jù)庫的時(shí)候，都可能把這塊功能給用起來。

　　03 standby上支持

　　比如讀寫分離場(chǎng)景，當(dāng)業(yè)務(wù)要求只讀查詢和之前寫入變更的事務(wù)之間必須有一個(gè)前后順序，很多時(shí)候我們的查詢不能發(fā)到只讀庫，因?yàn)椴恢�道只讀庫回放到什么時(shí)候了，有沒有把之前的修改回放過去，這種情況下，壓力還是得壓到主節(jié)點(diǎn)。

　　PG 19 有了WAIT FOR，當(dāng)我們做讀寫分離的時(shí)候，可以先做預(yù)判，判斷一個(gè)只讀節(jié)點(diǎn)是否已經(jīng)同步了之前寫入的事務(wù)，檢查回放進(jìn)度 LSN，回放到了，就把后面的請(qǐng)求轉(zhuǎn)發(fā)給這些只讀節(jié)點(diǎn)。這是一個(gè)很好的特性，值得我們持續(xù)關(guān)注后續(xù)應(yīng)用。

　　04 一些“補(bǔ)丁”能力：

　　當(dāng)一個(gè)表有很多索引時(shí)，特別是大表，以前每個(gè)索引是順序地(一個(gè)一個(gè))做垃圾回收，PG 19 的autovacuum可以并行地對(duì)多個(gè)索引同時(shí)做垃圾回收，這能大大縮短垃圾回收的總時(shí)間。

　　對(duì)于邏輯復(fù)制功能，不支持復(fù)制序列(SEQUENCE)，在 PG 19 里這個(gè)功能也補(bǔ)充上了。

　　企業(yè)升級(jí)策略：痛點(diǎn)驅(qū)動(dòng)升級(jí)

　　PG 19 要來了，不過很多用戶使用比較多的版本還是 PG16、PG17.大家對(duì)于新版本用得還不多，畢竟在生產(chǎn)環(huán)境下需要一個(gè)小心謹(jǐn)慎的態(tài)度。具體什么時(shí)候應(yīng)該升級(jí)?怎么用好新版本的能力?三位專家也根據(jù)具體場(chǎng)景給出了一些升級(jí)建議。

　　場(chǎng)景 1：云部署 + 大 I/O 操作

　　·如果你的數(shù)據(jù)庫跑在云盤上，且有頻繁的索引創(chuàng)建、垃圾回收、大表掃描

　　·建議升級(jí) PG 18.異步 I/O 帶來巨大的性能提升

　　場(chǎng)景 2：表膨脹困擾

　　·如果你的表經(jīng)常膨脹，存儲(chǔ)成本高，查詢性能下降

　　·建議等待 PG 19.內(nèi)核級(jí) REPACK 更穩(wěn)定，更放心

　　場(chǎng)景 3：信創(chuàng) + 跨 CPU 架構(gòu)

　　·如果你有信創(chuàng)需求，需要在 ARM 和 x86 之間做流復(fù)制或遷移

　　·建議升級(jí) PG 17/18.提供內(nèi)置的字符比較、排序比較，兼容性處理

　　場(chǎng)景 4: AI 應(yīng)用（Agent） + 知識(shí)圖譜

　　·如果你在構(gòu)建 AI Agent，需要存儲(chǔ)記憶、知識(shí)圖譜;需要單獨(dú)維護(hù)圖數(shù)據(jù)庫，數(shù)據(jù)同步復(fù)雜

　　·建議等待 PG 19.圖查詢是標(biāo)配能力，原生支持圖查詢，統(tǒng)一數(shù)據(jù)平面

　　具體場(chǎng)景挑戰(zhàn)很多，比如邏輯復(fù)制引起磁盤堆積問題、數(shù)據(jù)庫拷貝難題、外部表安全問題等等，根據(jù)自身業(yè)務(wù)的痛點(diǎn)和 PG 版本能力做匹配，是一種可靠的判斷邏輯。

　　另外，對(duì)于升級(jí)原則，德哥還分享了一個(gè)他的思路。對(duì)于相對(duì)傳統(tǒng)一點(diǎn)的企業(yè)，如果業(yè)務(wù)迭代速度或者變化節(jié)奏不是特別快，不用太著急去升級(jí)，遇到特別大的痛點(diǎn)，新版本能很好解決，這時(shí)候再考慮升級(jí)。對(duì)于業(yè)務(wù)本身變化極快的企業(yè)，可以考慮更快地使用新版本帶來的新特性，比如 PG 19 的圖查詢能力，可以給 AI Agent 相關(guān)的業(yè)務(wù)帶來極大助力，幫助提升應(yīng)用的競(jìng)爭(zhēng)力，那就可以偏激進(jìn)一點(diǎn)去使用新版本。

　　多元的社區(qū)貢獻(xiàn)指南：成長(zhǎng)于社區(qū)，貢獻(xiàn)于社區(qū)

　　PG 社區(qū)對(duì)新人非常友好，包容性強(qiáng)，那如何更好地在社區(qū)做共享?怎樣參與到 PG 下一個(gè)版本的新特性開發(fā)中?三位深耕于 PG 社區(qū)多年的專家分享了他們的經(jīng)驗(yàn)與建議。

　　1.從報(bào) Bug 開始：從使用者的角度，如果發(fā)現(xiàn)了 Bug，直接在 PG 官網(wǎng)按照模板提交。重要提醒：一定要寫清楚信息，包括詳細(xì)的環(huán)境信息(比如版本號(hào)、操作系統(tǒng)、硬件配置)，這個(gè)問題你是怎么復(fù)現(xiàn)的等等。如果只是填了一段報(bào)錯(cuò)上去，溝通效率會(huì)比較低。

　　2.寫插件：一上來就參加內(nèi)核貢獻(xiàn)，門檻還是稍微高了一點(diǎn)。PG 的插件生態(tài)非常廣，可以從插件入手。有什么好點(diǎn)子，或者在使用過程中遇到了一些問題，也許寫插件就能解決，那就先快速寫出來，也可以利用好 AI 工具來幫助實(shí)現(xiàn)。比如可以寫一些巡檢腳本，或者寫一些 Skills。等插件成熟了，社區(qū)可能會(huì)考慮將其引入內(nèi)核。

　　3.寫文章做分享：寫文章也是貢獻(xiàn)，比如可以從實(shí)際的案例出發(fā)，分享故障解決經(jīng)驗(yàn)、自己的思考和心得等等。

　　4.內(nèi)核貢獻(xiàn)三步法：第一步，觀察社區(qū)的溝通方式。先去郵件列表里邊看大家是怎樣交流溝通的，了解 Bug List，觀察代碼風(fēng)格，把這個(gè)流程或者大家的習(xí)慣梳理清楚。第二步，從小問題入手�？梢詮纳鐓^(qū)現(xiàn)有的 Bug List 里找痛點(diǎn)，先去解決好一個(gè)具體的小問題。第三步，大膽提交，接受反饋。PG 社區(qū)對(duì)新手特別友好，大佬們非常包容，不過 PG 的代碼審查很嚴(yán)苛，要有心理準(zhǔn)備，被拒絕是正常的，每一次反饋都是學(xué)習(xí)機(jī)會(huì)。

　　結(jié)語：PostgreSQL 的進(jìn)化哲學(xué)

　　從 PG 18 到 PG 19.PostgreSQL 的每一個(gè)特性都經(jīng)歷了反復(fù)討論與充分驗(yàn)證。PG 不追求激進(jìn)的創(chuàng)新，而是在穩(wěn)定性的基石上，穩(wěn)步演進(jìn)至最佳實(shí)踐。這種務(wù)實(shí)的進(jìn)化哲學(xué)，或許正是 AI 時(shí)代我們真正需要的。PG 19 將成為一個(gè)新的起點(diǎn)，未來，AI 時(shí)代下數(shù)據(jù)庫的更多可能性、更令人激動(dòng)的篇章，值得共同期待。

　　4 月 27 - 28 日，1 場(chǎng)主論壇+12 大主題分論壇，覆蓋數(shù)據(jù)庫技術(shù)的關(guān)鍵路徑與前沿方向，一次性展開 PostgreSQL 在當(dāng)下與未來的完整技術(shù)版圖。歡迎報(bào)名參加，我們濟(jì)南見。