背景

PostgreSQL 自第 11 版起引入了基於 LLVM 的即時編譯（JIT）技術，旨在加速複雜查詢中的表達式計算與數據轉換。然而，LLVM 雖然優化能力強大，其編譯開銷卻往往高達數十甚至數百毫秒，導致在處理中小型查詢或 OLTP 負載時，編譯時間反而超過了執行時間。針對此痛點，開源專案 pg_jitter 提出了輕量級的替代方案，透過整合 sljit、AsmJit 與 MIR 三種後端，將編譯延遲降低至微秒等級，試圖讓 JIT 在更廣泛的查詢場景中發揮價值。

社群觀點

在 Hacker News 的討論中，社群對於 PostgreSQL 現有的 JIT 實作普遍抱持保留態度。有開發者指出，在實際生產環境中，關閉 JIT 往往是更穩妥的預設選擇，因為 LLVM 帶來的效能波動過大，某些查詢甚至會因此出現劇烈的效能下滑，這種不確定性對於追求穩定性的資料庫系統而言並非好事。針對 pg_jitter 試圖解決的編譯延遲問題，部分討論者認為與其在執行時才進行編譯，或許應該考慮預先編譯（AOT）或快取 JIT 的結果，畢竟許多應用程式會反覆執行結構相似的查詢。

關於資料庫執行效率的討論也延伸到了直譯器的效能對比。有用戶分享其將 Python 邏輯移至 SQL 執行後，發現效能並未如預期般大幅提升，這反映出 PostgreSQL 內部的直譯器在處理通用邏輯時，效能可能與 Python 處於同一量級。社群認為，若像 PyPy 這樣的專案能為 Python 帶來數倍的加速，那麼專注於特定 SQL 運算的資料庫編譯器理應有更大的優化空間，但這需要極高的技術門檻與資金投入。

此外，討論中也涉及了現代技術如人工智慧是否能協助優化編譯器。雖然有意見認為可以利用 AI 來合成針對特定架構的編譯器，但隨即遭到反駁，認為大型語言模型（LLM）目前的延遲過高且具備非確定性，並不適合直接參與資料庫底層的編譯過程。不過，社群也澄清，AI 的價值可能在於輔助開發者撰寫或設計更高效的編譯器工具，而非直接取代編譯流程。最後，有資深開發者提到，相較於 Oracle 或 SQL Server 等商用資料庫巨頭已發展數十年的 JIT 技術，開源社群在這一領域仍有長足的進步空間，而 pg_jitter 的出現正是填補這一技術鴻溝的積極嘗試。

延伸閱讀

• PostgreSQL 官方文件關於預編譯陳述式（Prepared Statements）的說明，這是應用端參與效能優化的另一種途徑。