ITPub博客

设想如下数据库场景：两张表通过外键关联，外键字段为 NOT NULL，且约束有效并被严格执行。在执行两表 JOIN 查询时，却返回空结果。该场景看似不可能出现，但实际生产环境中出现了一个未被预期的边界情况。问题场景假设以车辆所有权管理场景为例，包含两张表，分别是车主表与车辆表：db=# CREATE TABLE owner (   &n

在数据库系统中，查询往往受限于 I/O 性能，因此优化工作通常聚焦于减少页面读取次数。索引是典型手段之一，但无法解决所有问题。Postgres 通过在表主存储（heap）及索引中维护多版本行数据，以支持并发查询的一致性。旧版本行在不再需要前仍占用空间，并可被后续复用。这部分额外空间通常称为“膨胀（bloat）”。本文将分析堆表膨胀与索引膨胀对查询性能的影响，以及对应的预防与处理方案。在 pgMus

在开发实践中，经常会遇到一个问题：如何在不修改 PostgreSQL 内核代码的前提下，为数据库对象附加自定义元数据。本文展示了一种基于 PostgreSQL SECURITY LABELS 机制的可行方案，用于实现自定义属性。这种方式具备事务性、与数据库对象强关联，并且能够与标准 PostgreSQL 操作良好协同。问题背景：复制冲突的管理在一个典型的两主节点向第三节点复制数据的架构中，UPDA

分区表是 PostgreSQL 的核心特性之一，但有一个问题即便资深用户也常会产生困惑：在涉及分区时，ALTER TABLE 语句的具体执行逻辑是怎样的？操作是否会同步至各分区？是否对新建分区生效？ONLY 关键字是否实现预期效果？为何部分命令可在主表执行却无法在分区执行，或反之？当前 PostgreSQL 官方文档对单个 ALTER TABLE 子命令的说明较为完善，但很少系统性地解释它们在分区

在使用 PostgreSQL 数据库的过程中，有一组实践方式可以显著提升开发与协作体验。单个做法影响有限，但叠加起来效果十分明显。使用 UUID 作为主键UUID 确实存在一些缺点：完全随机的 UUID 无法自然排序，对索引有一定影响相比自增 ID 占用更多存储空间（而存储通常是成本最低的资源）但 UUID 的优势远大于缺点：生成 UUID 无需与数据库协调可以安全地对外公开和传递CREATE&n

关于作者：Nickyoung，数据库领域从业者。PostgreSQL ACE，IvorySQL 专家顾问委员会成员。公众号“👉PostgreSQL 运维之道”。还在以最终 cost 来判断计划是否最优？那就大错特错了！！！本篇老杨和大家一起抽丝剥茧，从源码入手分析计划跑偏的原因。问题现象一个简单查询运行 240s，从执行计划看耗时主要在 nestloop join，Outter 扫描了 2293

PostgreSQL 18 正式发布，带来了多项重要改进，其中 RETURNING 子句的增强尤为突出。该特性在 MERGE RETURNING 场景下实现了关键突破，可显著简化应用架构，并提升数据变更追踪能力。RETURNING 子句的演进RETURNING 子句长期以来用于在 INSERT、UPDATE、DELETE 操作后返回受影响行的数据，从而避免额外的 SELECT

关于作者：Nickyoung，数据库领域从业者。PostgreSQL ACE，IvorySQL专家顾问委员会成员。公众号 “ 👉 PostgreSQL 运维之道 ”。给大家分享一个有趣的案例，同一个 sql，索引扫描比全表顺序扫描获取的数据更少。本篇我们深入分析一起索引排序规则损坏的案例，并 debug 验证索引扫描的主要过程。问题现象走索引扫描查询到 1 条数据。testid

PostgreSQL 在各行各业的关键应用中具有极高适用性。尽管 PostgreSQL 提供了良好的性能，但仍存在一些用户不太关注但对整体效率与速度至关重要的问题。多数人认为增加 CPU 核数、更快的存储、更大内存即可提升性能，但还有同样重要的因素需要关注——那就是延迟。延迟意味着什么？数据库执行查询操作的耗时，仅占应用程序接收查询结果总耗时的极小部分。下图可直观呈现该过程的内在逻辑：客户端应用发

在 PostgreSQL 中，SQL 查询的解析、执行等全流程的触发，均以应用程序与数据库建立有效连接为前提。这一连接建立过程看似是简单的交互握手，实则背后蕴含复杂的底层机制——涵盖进程管理、身份认证，以及保障高效通信的二进制协议等核心环节。深入理解 PostgreSQL 的连接处理机制，不仅能明晰连接池的重要性、掌握连接问题的排查思路，还可厘清其架构与基于线程的数据库的本质差异。下文将完整梳理应

作者简介：怀玉杰，瀚高股份研发工程师，负责 AI 方向研发，擅长算法分析与 AI 应用。医院数据管理的挑战介绍当前医院的信息系统呈现出多系统并存的复杂局面。一家三甲医院通常运行着数十个不同的业务系统：HIS（医院信息系统）处理核心业务，EMR（电子病历系统）记录诊疗过程等。并且医院场景本身复杂多变，患者从入院到出院整个过程往往要经历多个阶段：入院登记、床位分配、科室调整、检查与治疗、最终出院。以床

当输入 SELECT * FROM users WHERE id = 42;并执行时，这条看似简单的 SQL 语句，实际上会在 PostgreSQL 内部触发一段复杂而精密的处理流程。该过程涉及多个后台进程、精细的内存管理机制，以及数十年数据库优化研究的成果。查询执行的五个阶段无论查询复杂与否，在 PostgreSQL 中都会经历同一条基本路径：解析（Parsing） → 分析（Anal

什么是约束在定义表或列时，可以为数据附加校验或强制规则的，这些规则称为约束。数据类型本身只能提供较粗粒度的限制，例如 numeric 无法限定只能为正数。更具体的规则（如唯一性、取值范围等）需要通过约束来实现。约束用于保障数据完整性。当插入或默认值违反约束时，PostgreSQL 会直接报错。本质上，约束是数据库层面强制执行的数据规则。一旦缺失或使用不当，数据问题往往会悄然积累，并最终演变为难以排

在 Greg Sabino Mullane 编写的最新 Postgres 补丁中，Postgres 对数据完整性机制进行了调整：从 Postgres 18 开始，数据校验（data checksum）功能默认启用。这一变更在发布说明中看起来只是一个相对较小的调整，但针对的是数据库运行过程中较难察觉的风险之一—静默数据损坏（silent data corruption），对系统可靠性具有实际意义。本

PostgreSQL 以固定大小的数据块（Page）存储数据，默认大小为 8 KB。当客户端执行更新或插入操作时，PostgreSQL 并不会立即将变更写入磁盘，而是先将相关数据页加载到共享内存（Shared Buffers）中，在内存中完成修改，并将该页面标记为“脏页”。所谓“脏页”，是指内存中的页面版本已经新于磁盘上的对应版本。在向客户端返回操作结果之前，PostgreSQL 会先将变更记录写

对于任何需要维护超大表（更新旧数据、分批删除、数据迁移）的 DBA 或开发者来说，使用 ctid（元组物理位置）将大表切分为多个小块进行处理是标准操作。然而，直到现在，这种操作都有一个巨大的痛点：它严格依赖单进程。随着最近的一个 Commit (0ca3b169) 合并入 PostgreSQL 19 (master 分支)，TID 范围扫描（TID Range Scans）终于支持并行了

PostgreSQL 18 正式发布后，PostgreSQL 19 的性能改进方向已经引发广泛关注。其中，聚合性能的重大优化被认为是最 具突破性的改进之一，并且这一优化对现有应用完全透明，无需修改代码、无需调整参数，即可直接生效。PostgreSQL 中的数据聚合在 PostgreSQL 此前的版本中，聚合的基本执行规则是：先关联（Join），后聚合（Aggregate）典型示例如下：SELECT

Postgres 18 于 2025 年 9 月 25 日发布，带来了多项性能增强和新功能。随着版本迭代，Postgres 在关键业务与非关键业务场景中均表现出更高的稳健性、可靠性和响应能力。Postgres 18 包含多项实用增强特性，此前已被关注的异步 I/O（AIO）子系统便是重要性能优化之一。该特性能够提升顺序扫描、位图堆扫描和 VACUUM 操作期间的 I/O 吞吐量，可为多数 Post

PostgreSQL 18 引入了一项强大的新功能，允许你在时间段内强制执行唯一性：时间约束（Temporal Constraints）。通过这一新增功能，你现在可以在定义 UNIQUE、PRIMARY KEY 或 FOREIGN KEY 约束时，利用日期范围（Date Range）或时间戳范围（Timestamp Range）字段，比以往更容易地防止数据重

在 PostgreSQL 18 中，你会在 EXPLAIN ANALYZE 的输出结果中看到 “Index Searches”（索引搜索次数）相关行。如果你和我一样好奇这些行到底是什么意思，那这篇文章就是为你准备的。标准情况标准情况是 “Index Searches: 1”，表示对索引进行一次遍历。如果所需数据都集中在索引的同一区域，这种情况可能非常高效。但如果所需条目并非集中存储，那么扫描过程中