資料與儲存 2026 年 5 月 26 日

2026-05-26 — pg_tre 1.1.1 近似正規表達式索引、pg_statviz 1.0 AI 分析、Redis 長時程代理上下文引擎

primary=https://www.postgresql.org/about/news/pg_tre-111-released-an-approximate-regex-index-am-for-postgresql-18-3305/ primary=https://codeberg.org/gregburd/pg_tre primary=https://www.postgresql.org/about/news/pg_statviz-10-released-with-ai-powered-analysis-3301/ primary=https://redis.io/en/blog/long-horizon-ai-agents-memory-state-infrastructure/

pg_tre 1.1.1:PostgreSQL 18 的近似正規表達式索引存取方法,三層漏斗架構實現毫秒內模糊搜尋

PostgreSQL News · 2026-05-22

pg_tre 1.1.1 釋出,這是一個 PostgreSQL 18+ 的原生索引存取方法(Index Access Method),支援帶有 Levenshtein 距離預算的近似正規表達式比對——讓你可以用 SQL 查詢「與 error 最多相差一個字元的所有文字」並且索引加速,在百萬筆資料中達到毫秒級回應。

背景:近似正規表達式的需求

傳統正規表達式索引(如 PostgreSQL 的 pg_trgm)只支援精確字元比對,無法處理拼寫錯誤、OCR 錯誤或跨語言音譯的查詢場景。Levenshtein 距離模糊比對雖然可行,但在大型資料集上線性掃描代價過高。pg_tre 透過三層漏斗架構解決這個問題,底層使用 Ville Laurikari 的 TRE 函式庫執行 NFA-based 近似正規表達式比對。

三層漏斗架構

  • BRIN-style range bloom filters:粗粒度範圍過濾,快速排除整個 page 範圍
  • Sparsemap trigram postings:中間層 trigram 倒排索引,縮小候選集
  • Per-tuple bloom filters:細粒度每行過濾,進一步排除
  • TRE library heap recheck:對剩餘候選行執行精確 Levenshtein 驗證

規格細節

索引支援每子表達式獨立設定編輯距離預算,例如:

CREATE INDEX docs_body_tre ON docs USING tre (body);

-- 找出 body 中包含「最多 1 次編輯」的 error 的記錄
SELECT id FROM docs
 WHERE body %~~ tre_pattern('(error){~1}', 1);

功能包含:完整 WAL 覆蓋與 VACUUM 感知、REINDEX CONCURRENTLY 支援、UTF-8 正確處理(CJK、重音字元、emoji),以及針對 DoS 的可設定 NFA 狀態數量上限。對「從百萬筆資料中回傳少數幾行」的查詢,通常達到毫秒以下的回應時間

影響範圍

pg_tre 最適合的場景包含:日誌搜尋(同時找 timeouttimeoutt)、產品目錄 SKU 查詢(容忍數字轉置或缺失)、以及 hybrid RAG 管道中補充 pgvector 語意搜尋的模糊詞彙層。pg_tre 是 PostgreSQL 18 的 Index AM API(IndexAmRoutine)的直接實作,不需要任何 contrib 擴充之外的核心修改。

原始來源:PostgreSQL NewsCodeberg: gregburd/pg_tre


pg_statviz 1.0:PostgreSQL 時序統計視覺化加入選配 AI 分析,支援 Claude、Gemini 與 Ollama

PostgreSQL News · 2026-05-21

pg_statviz 1.0 正式釋出,這是一個用於 PostgreSQL 內部統計時序分析與視覺化的擴充套件。1.0 的重要新功能是選配的 AI 分析模式--ai 旗標),可調用視覺能力 LLM 以 Senior PostgreSQL DBA 的角色分析統計圖表,回傳 [HEALTHY]/[WARNING]/[CRITICAL] 判決與修復建議,完全不需要安裝代理或建立外部連線。

時序分析範圍

pg_statviz 分析 PostgreSQL 的核心統計數據,包含:

  • Buffersshared_buffers、bgwriter 統計
  • Checkpointscheckpoint_*max_wal_size 趨勢
  • Connectionsmax_connections 使用率
  • WAL 活動:寫入量趨勢、LSN 進展
  • Session 活動:活躍連線、等待事件分佈

工具生成每個模組的獨立 HTML 報告(含嵌入圖表 PNG),以及跨模組關聯分析的彙整 index.html

AI 分析設計

AI 功能的技術設計有幾個值得注意的細節:確定性規則引擎在 LLM 分析前先驗證資料,排除統計異常值後再送入 LLM;提示詞包含 <user_data> 封裝以防止 prompt injection;LLM 的上下文包含實際的 pg_settings 值,讓建議更具針對性。支援三個 AI 提供者:

  • --ai claude(Anthropic Claude,預設)
  • --ai gemini(Google Gemini 2.5 Flash)
  • --ai local(本地 Ollama,例如 gemma4:e4b

影響範圍

不使用 --ai 旗標時,pg_statviz 與舊版完全相同,AI 功能是純加法的選配。對於需要定期生成資料庫健康報告的 DBA,AI 分析層可以將「看圖表→判斷→建議」的流程自動化,作為 24/7 監控的補充。pg_statviz 本身以 Python 撰寫,安裝為 PostgreSQL 擴充套件搭配 CLI 工具。

原始來源:PostgreSQL News — pg_statviz 1.0


長時程 AI 代理的記憶與狀態基礎設施:Redis 作為跨小時甚至跨天的上下文引擎

Redis Blog · 2026-05-21

隨著 AI 代理從「單輪對話」演進為「執行數小時或數天的長時程任務」,傳統的 LLM 上下文視窗已不足以維持狀態。Redis Iris 提出以 Redis 作為代理的「上下文引擎(context engine)」,解決長時程代理在記憶持久性、即時狀態查詢與多代理共享上下文三個面向的挑戰。

長時程代理的狀態問題

短代理(< 1 分鐘)可以把所有狀態放進一個 LLM 呼叫的 context window。長時程代理面臨的問題是狀態量遠超上下文視窗上限:一個執行 8 小時的代理可能需要追蹤數千個中間決策、工具呼叫結果與環境觀察,不可能全部放入單一 prompt。此外,若代理需要暫停後繼續執行(例如等待人工審批),狀態必須持久化到外部儲存。

Redis 作為上下文引擎的三個功能層

  • 語意記憶(Semantic Memory):以 Redis Query Engine 的向量搜尋功能,將過去的觀察與決策編碼為向量,在需要時檢索最相關的歷史記憶注入當前 prompt
  • 短期工作記憶(Working Memory):利用 Redis 的低延遲讀寫,在代理執行迴圈的每一輪快速讀取當前任務狀態與工具呼叫結果
  • 多代理共享上下文(Shared Context):多個子代理透過 Redis 的 Pub/Sub 或 Streams 共享觀察結果,避免重複感知或衝突行動

影響範圍

Redis 在這個場景的關鍵優勢是延遲極低(P99 < 1ms)與豐富的資料結構:Hash 用於結構化狀態、List 用於代理行動歷史、Sorted Set 用於優先佇列。對正在設計長時程代理基礎設施的工程師,這篇文章提供了一個完整的架構參考,包含向量搜尋、持久化、多代理協調的組合方式。

原始來源:Redis Blog


End of article
0
Would love your thoughts, please comment.x
()
x