展望 Postgres 19

原文 ↗ Hacker News 讨论 ↗

感知到的遗漏与值得注意的 PG19/PG 路线图特性

  • 评论者指出，文章淡化了诸如原生应用时间临时表（SQL:2011 风格）和查询提示等重要新增功能，而这些功能此前曾引发关注。
  • 新的图查询（SQL/PGQ）吸引了注意；有人觉得其语法笨拙，并质疑性能，尤其是考虑到过去行级安全相关的 planner 问题。
  • GROUP BY ALL 广受好评，被认为是一个小但非常实用的 SQL 易用性改进。
  • 对 COPY 和逻辑复制的改进受到欢迎，因为这能带来更轻量的备份；有些人已经为了备份单独运行了很重的 sidecar 实例。
  • PG18 中的异步 I/O 被提到是迁移离开 16 的一个强大动机。

AI 生成内容与 HN 讨论质量

  • 一个很长的分支在争论这篇帖子是否由 LLM 撰写。有些人依赖 Pangram 之类的工具；另一些人强调这类检测器并不能可靠地证明什么。
  • 一些人对他们所看到的“LLM 垃圾”式通用散文在 HN 上变得普遍感到沮丧，许多不同博客现在共享相同的语气和结构。
  • 另一些人则认为，对 AI 的元讨论不如直接参与技术内容更有价值，不过支持者表示，识别非原创、被 AI 洗过的作品符合 HN 的规范。
  • 有人提到 Snowflake 因 AI 解雇了技术写作者，并对误导性的人工作者身份声明表示担忧。

Postgres 与其他数据库

  • 许多生产环境用户对 Postgres 持积极态度，但仍希望有：
    • 轻量级连接（每连接一进程被视为比线程化服务器更重）。
    • 类似 SQL Server 那样可同步维护的物化/索引视图。
  • SQL Server 因其索引视图、快照隔离、强大的工具链（SSMS、Visual Studio、RedGate）以及列存索引而受到称赞，不过有些人认为其生态在老化、对 Windows 的依赖令人痛苦，而且 MERGE 语义有问题。
  • 对 MySQL/MariaDB 的批评包括：JSON 实现薄弱、缺少事务性 DDL/merge/partial indexes、严格性问题、历史上的类型/UTF-8 异常行为，以及复制/DDL 的痛点。
  • Oracle 则因空字符串等于 NULL 之类的语义，以及供应商/法律/商业负担而受到严厉批评。

扩展性、存储引擎与分析

  • 多位用户希望有可插拔存储引擎：LSM（例如类似 RocksDB）、append-only，或原生列式/块压缩。
  • 提到的例子包括 Salesforce 在 Postgres 上使用 LSM、OrioleDB（但仍需核心补丁），以及像 cetus 这样的列式/分析扩展，或者一个新的类似 Delta 的扩展。
  • 这里存在一种张力：
    • 一方希望 Postgres 通过可插拔/列式存储演进，以便直接处理非常大的科学/分析工作负载。
    • 另一方认为列式 OLAP 数据库是不同类别，建议用 Postgres 处理 OLTP，再通过 CDC 或 ETL 配合单独的数据仓库（ClickHouse、DuckDB 等）。

运维、生态与文化

  • 原地大版本升级仍然是痛点，尤其是在 Docker 场景下。
  • 连接/进程模型与 MSSQL 的线程模型之间的比较，围绕可扩展性、健壮性和计划缓存展开讨论。
  • 一些人认为 Postgres 实际上正在取代新应用栈中的 MySQL（“PHP/MySQL → Python/Postgres”），并指出 Snowflake、Databricks、ClickHouse 等大型数据平台如今都提供托管 Postgres，这被视为时代的标志。
  • 有用户请求高级 Postgres 学习资源；回复是其特性面非常广，因此推荐会高度依赖具体兴趣。