PG 18 最受喜爱的3个特性，你同意吗？

PostgreSQL 18 最受喜爱的3个特性

PostgreSQL 每个大版本差不多在4月份就封版了, 如果你要了解PG18的功能细节, 可看我4月份时写过的这篇文章汇总:

• 《PostgreSQL 18 功能整理汇总 : 14以来最值得期待的版本》

现在是9月份, 经历了3个beta版本后, PostgreSQL迎来了发布Release前的RC1版本.

快release, 各种消息已经满天飞, PG 18被谈及最多的3个功能是什么呢?

下面我们来看一下这篇文章的介绍, 和我想的差不多: https://stormatics.tech/blogs/3-features-i-am-looking-forward-to-in-postgresql-18

我期待 PostgreSQL 18 中的 3 个功能

又到了一年一度的黄金时节。PostgreSQL 18 的第一个候选版本已经发布，前景一片光明。我们预计它将在未来 2-4 周内正式发布。

激动人心的时刻！

在过去的多年中，PostgreSQL 社区在每年的发布过程中都做出了卓越的贡献，平均每个版本都会发布 150 多个新功能！

对于即将推出的 v18，以下是我最兴奋的三大功能：

1 - 异步 I/IO

PostgreSQL 18 通过其异步 I/O（AIO）子系统引入了重大的内部变化，从根本上改变了数据库执行磁盘读取的方式。

最大的好处是使得PG的I/O吞吐变强了, 最直接的体现是在云盘/网络存储环境中OLAP查询性能显著提升.

异步 I/O 的作用

过去，PostgreSQL 的磁盘读取操作是同步的：每个后端进程都会调用操作系统，等待数据到达，然后继续处理。这种“一次一个块”的模型会导致 CPU 在存储速度较慢时（尤其是在网络连接磁盘上, 说的就是你, 云盘）处于空闲状态，从而限制了吞吐量。新的子系统允许后端同时对多个读取请求进行排队，从而允许在获取数据的同时继续进行其他工作。当请求的块准备就绪时，PostgreSQL 会将它们直接复制到共享缓冲区中，从而无需依赖内核的预读启发式算法。

工作原理

1. io_method – 新增的GUC参数：

sync - 采用旧的同步 I/O 行为。

worker - 使用专用的 I/O 工作进程。主后端worker process将读取请求入队，并在这些工作进程与内核交互时继续执行。您可以通过 io_workers 配置工作进程的数量。

io_uring - （仅限 Linux）利用内核的高性能 io_uring API 来提交和完成 I/O 请求，而无需单独的工作进程。

2. 调优与监控 – 新增变量 io_combine_limit 和 io_max_combine_limit 参数, 决定单个请求中可以合并多少个相邻块。effective_io_concurrency 和 maintenance_io_concurrency 的默认值已提升至 16，这更好地体现了现代硬件的性能，并允许在顺序扫描中实现更多预读操作。pg_aios 视图会显示待处理的异步 I/O 操作以供监控。

3. 适用场景 – 在 PostgreSQL 18 中，AIO 涵盖顺序扫描、bitmap heap scan以及 VACUUM 等维护操作。写入操作保持同步（目前）。

为什么重要

降低延迟，提升吞吐量 —— 基准测试表明，启用 AIO 可以使冷缓存环境下的读取性能提升一倍甚至三倍。使用worker或io_uring时，对 3.5 GB 表进行简单的COUNT(*)操作，所需时间分别从约 15 秒和约 10 秒下降到约 5.7 秒。这在具有网络延迟存储的云环境中尤其有益，因为在云环境中，单个读取操作可能需要几毫秒。

更好的资源利用率 —— 通过同时发出多个读取，PostgreSQL 减少了空闲 CPU 时间并更有效地利用可用的 I/O 带宽。

增强 DBA 的控制力 – 管理员可以微调并发度（通过 effective_io_concurrency 和 io_combine_limit ），选择最适合其环境的 io_method ，并使用 pg_aios 监控未完成的操作。默认 effective_io_concurrency 现已为 16。

总而言之，PostgreSQL 18 中新的异步 I/O 子系统允许多个未完成的读取请求，从而降低 I/O 延迟的影响并提高读取吞吐量。它引入了灵活的选项（sync 、worker 、io_uring ）和新的调优参数，早期基准测试表明，顺序扫描和维护任务的性能显著提升，尤其是在云和NAS网络存储环境中。

2 - UUID v7

PostgreSQL 18 的uuidv7()函数在分布式数据库环境中很重要，因为它允许集群中的每个节点或客户端在没有中央协调器的情况下生成唯一的、有序的标识符。

为什么传统唯一标识的协调存在问题

自动递增整数需要单一事实来源以避免冲突。在分片或多主服务器设置中，跨节点协调序列号会导致网络延迟，并且如果序列生成器发生故障，还存在停机风险。

随机 UUID (v4) 解决了全局唯一性问题，因为每个节点都可以独立创建一个 ID，但其随机性会导致插入操作分散到整个 B 树索引中。这种较差的局部性意味着最新记录会被写入磁盘上的任意位置，从而导致更多的索引页分裂 和 缓存未命中率提升。

参考文章：

• 《PostgreSQL 无序UUID的问题和优化》
• 《PostgreSQL 优化CASE - 无序UUID性能问题诊断》

UUID v7 如何改进分布式数据库系统

本地生成，全局唯一 —— 与其他 UUID 一样，版本 7 的值是 128 位标识符，可以在任何位置生成，无需协调。这使得它们非常适合分布式系统、微服务和多主数据库，因为这些系统中每个节点都必须生成唯一的 ID。

时间排序 – UUID v7 将当前 Unix 时间戳（精度为毫秒）编码在其最高 48 位，其余部分使用随机位。由于时间戳部分单调递增，因此在索引中，大致相同时间生成的值相邻。基准测试表明，与随机 UUID 相比，按时间排序的 UUID 可显著减少预写日志 (WAL) 的体积，并提高索引局部性。这意味着插入操作基本遵循顺序模式，从而提高写入性能和缓存命中率。

易于合并 且 可预生成 —— 当需要合并来自不同分片或离线服务的数据时，UUID 可以避免冲突，因为它们发生冲突的概率几乎可以忽略不计。客户端可以提前生成 ID（例如，在浏览器中），然后稍后提交；这减少了与数据库的往返次数，并简化了离线工作流程。

概括

在分布式生产环境中，使用uuidv7()作为主键可以提供：

去中心化唯一性 —— 每个分片或客户端都可以创建无需中央协调的 ID，从而避免了分布式序列生成器的复杂性。

有序的、索引友好的插入 - 基于时间的前缀意味着新的 ID 聚集在 B 树的“最右侧”，从而保留索引局部性并提高插入和读取性能。

对于必须水平扩展同时保持性能的分布式数据库，uuidv7()提供了一个实用的解决方案：全局唯一标识符，可自然排序且对数据库索引高效。

3 - OAuth 2.0 身份验证

PostgreSQL 18 添加了原生 OAuth 2.0 身份验证方法，允许数据库接受基于标准的承载令牌 (Bearer token) 而非密码。此功能由服务器端身份验证钩子和 libpq 中的新客户端选项组成。

OAuth 方法的工作原理

1. pg_hba.conf中新增oauth条目 - 当您在pg_hba.conf中指定oauth作为身份验证方法时，PostgreSQL 要求客户端提供 OAuth 2.0 持有者令牌。令牌符合 RFC 6750 规范，并由pluggable library 进行验证。服务器必须使用 –with-libcurl 选项进行编译才能启用此功能。

2. 持有者令牌验证 —— 验证由OAuth validator library处理。GUC oauth_validator_libraries列出了实现令牌验证的共享库；如果加载了多个，则pg_hba.conf条目中的验证器选项会选择使用哪一个。验证器通常执行令牌自检或调用身份提供者的/userinfo端点。

3. 连接特定参数 —— 连接时，libpq 客户端可以提供几个新参数（在连接字符串或环境中）：

oauth_token （或设备流参数）—— 要呈现的承载令牌；libpq 还支持 OAuth 2 设备授权流程，用于以交互方式获取令牌。

issuer – 身份提供者/授权服务器的 HTTPS URL；它必须与提供者的发现文档中的发行者匹配。

scope – 客户端所需范围的空格分隔列表。

validator —— 如果配置了多个验证库，则使用哪个验证库。

map – 从 OAuth 身份到 PostgreSQL 角色名称的可选映射规则。

delegate_ident_mapping – 让验证器库无需参考pg_ident.conf即可决定用户角色映射；这以完全信任验证器为代价提供了灵活性。

为什么这很有用

与企业 SSO 集成 - OAuth 2.0 是基于令牌身份验证的行业标准。凭借原生支持，PostgreSQL 可以直接与 Okta 或 Azure AD 等身份提供商集成，无需代理或自定义钩子即可实现单点登录和集中式用户管理。

更强大的安全性和合规性 —— 持有者令牌可限定范围、有效期短且可撤销。使用令牌可避免在应用程序中存储长期密码，并且在身份提供者中撤销令牌会立即阻止数据库访问。管理员可以通过设置范围参数来强制执行细粒度的范围限制，例如将令牌限制为只读查询。

客户端支持 – libpq 实现了 OAuth 设备授权流程 (RFC 8628)，并接受直接在连接字符串中提供的令牌，从而使psql等命令行工具能够通过 OAuth 进行身份验证，而无需手动复制令牌。当服务器的issuer参数与客户端的oauth_issuer匹配时，连接将继续进行；否则将被拒绝。

总之

PostgreSQL 18 中的 OAuth 特性带来了对 OAuth 2.0 持有者令牌的一流支持。服务器管理员可以配置pg_hba.conf以使用oauth ，通过oauth_validator_libraries指定令牌验证器，并定义身份到角色的映射。客户端可以出示令牌或使用设备流程动态获取令牌。此功能支持现代 SSO 集成、集中式访问控制和基于令牌的安全性，而无需依赖外部代理或自定义身份验证机制。