Source: https://aiven.io/developer/postgresql-jsonb-cheatsheet

从 9.0 开始，PostgreSQL 基金会为每个发布版本创作一个 Release Artwork，从版本 12 开始，PostgreSQL 基金会把这个 Artwork 制作成 challenge coin 送给该版本的所有贡献者留作纪念。 今年的艺术品名称是 a baker making cloud cakes with jays on (pun) the apron，即一个穿着印有松鸟围裙的面包师傅制作云朵蛋糕。 PostgreSQL 选择大象作为 Logo 是因为 “elephants can remember”，所以每个 Artwork 也都以大象为主题。 对于一个开源项目，这种文化非常值得赞扬。通过向贡献者赠送一个小而用心的礼物，让他们感受到强烈的归属感。这种举动表达了对他们的感谢，同时也激励他们继续为项目做出贡献。

I know it seems dumb, but postgres really needs to add the simple developer experience stuff like: SHOW CREATE TABLE; SHOW TABLES; SHOW DATABASES; SHOW PROCESSLIST; CockroachDB added these aliases ages ago. 如上是 Hacker News 今年 5 月的一个帖子，相信 PostgreSQL 的用户都知道，PostgreSQL has its own way!!! 是的，我们用 slash commands，并且热衷这种简洁的方式: MySQL PG show create table t; \d+ t show tables; \d show tables like "%test%" \dt public.*test* show databases; \l show processlist; SELECT * from pg_stat_activity; 不过 slash commands 只能在 psql 中使用，psql 将相应的命令转换成对应的 SQL 查询发送到 server 端处理。大多情况下，这种方式能满足用户的需求，但也有例外，比如:...

PostgreSQL 的多进程架构相对于多线程架构有什么优势？如果你认同 “一个查询的后端进程崩溃不会影响其它连接的后端进程，从而提高了系统稳定性” 是其中一个优势，那请继续看下去 🐘。 postmaster 状态机 postmaster 作为 PostgreSQL 的主进程，在启动时负责创建共享内存和信号量。然而，它自身几乎不直接操作这些资源（当然也有例外，如 PMSignalState），这样的设计使得 postmaster 逻辑更简单、更可靠。当后端进程崩溃时，postmaster 通过重置共享内存和信号量来恢复系统的正常运行。 当 postmaster 接收到客户端请求时，它会立即派生（fork）一个子进程。子进程负责对请求进行权限验证，如果验证成功，则成为一个后端进程，这种设计保证了客户端请求的高效处理。 postmaster 负责启动一系列子进程，包括辅助（Auxilary）进程和普通（Normal）后端进程，其中 startup 进程跟 postmaster 紧密合作来保证数据库的一致性，它调用 StartupXLOG 执行数据库恢复的流程（本文不展开 recovery 的流程）。 postmaster 被实现为一个状态机，父子进程之间通过信号（signal）进行交互，如下是 postmaster 的状态图: postmaster 启动后初始状态为 PM_INIT，完成一些初始化工作后，启动 startup 进程，postmaster 进入 PM_STARTUP 状态 如果 startup 进程完成其工作并正常退出（OS 给 postmaster 发送 SIGCHLD 信号），postmaster 进入 PM_RUN 状态 startup 进程在进行到可以开始 archive recovery 时，给 postmaster 发信号并在共享内存标记 PMSIGNAL_RECOVERY_STARTED，postmaster 处理后进入 PM_RECOVERY 状态 startup 持续重放 wal 日志，如果开启了 Hot Standby，当达到一致状态后，会标记 PMSIGNAL_BEGIN_HOT_STANDBY，postmaster 进入 PM_HOT_STANDBY 状态 postmaster 在 PM_RUN 和 PM_HOT_STANDBY 状态都可以接收请求连接，因此这里把两个状态放在了一起 当有后端进程异常退出后，postmaster 进入 PM_WAIT_BACKENDS 状态，并调用 HandleChildCrash 来通知其它进程退出 所有进程退出后，postmaster 进入 PM_NO_CHILDREN 状态，然后重建共享内存和信号量并启动 startup 进程，postmaster 状态改为 PM_STARTUP 可以看出，一个后端进程的异常退出会影响其它子进程。一个简单的验证方法是使用 kill -9 去杀死一个查询的后端进程，并查看其它后端进程的 pid 是否改变，参考 KILL -9 EXPLAINED FOR POSTGRESQL。...

在进行技术选型时，需要考虑众多因素，如功能、性能、可靠性、成本效益、社区支持和团队技术能力等，然而，影响最终决定的关键因素的往往是团队 Leader 的技术品味，这也能解释为什么阿里偏爱 Java，而字节跳动更倾向 Go、Rust 等新兴语言。技术本身无好坏之分，根据实际业务问题选择适当的技术方案是关键。 本文旨在为读者提供一种新的选择，而非论证 PostgreSQL 比 MongoDB 更优秀。 MongoDB 因其灵活的 “Schema-less”（无模式）特性而著名。“Schema-less” 意味着 MongoDB 不要求严格定义数据的结构和字段（使用 BSON 格式存储数据），允许在同一集合中存储具有不同结构的文档，这为开发人员提供了更大的灵活性，能够轻松地适应数据模型的变化和演进。 PostgreSQL 提供的 JSONB 类型可用于存储和处理 JSON 数据，包括嵌套的对象、数组和基本数据类型。因此，PostgreSQL 具备 MongoDB 存储 document 的能力。 PostgreSQL 对 JSON 的支持 我们来了解一下 PostgreSQL 支持 JSON 特性的时间线（统计到版本 14）: - PG 9.2 Introduction of JSON (JSON text; no indexes) -- 2012/9/10 - PG 9.4 Introduction of JSONB (binary format; indexes) -- 2014/12/18 - PG 9.5 jsonb_set(), jsonb_object(), jsonb_build_object(), jsonb_build_array, jsonb_agg, || operator etc....

数据库连接池（Connection Pooler）是一种用于管理和复用数据库连接的组件，它允许应用程序在需要与数据库建立连接时从连接池中获取连接，而非每次都创建新的连接，以减少连接创建和销毁的开销。今天我们介绍 PostgreSQL 数据库生态中常用的四个具有连接池能力的工具: PgBouncer、Pgpool-II、Odyssey、PgCat。 为什么需要连接池? 通常 DBA 会给 PostgreSQL 实例设置一个合理的 max_connections 值，当连接数超过这个值后会报 FATAL: remaining connection slots are reserved for ... 的错误。 有些人认为 PostgreSQL 不能处理太多连接是因为它的进程模型（为每个连接创建一个 backend 进程）会占用大量内存，但其实更重要的原因是 Snapshot scalability，当有大量连接（即使状态为 idle）时，获取快照信息（GetSnapshotData）成为了性能瓶颈。 PG 14 针对 Snapshot scalability 的问题进行了优化: Improving Postgres Connection Scalability: Snapshots，降低了 idle 状态连接对数据库性能的影响，因此我们现在可以把 max_connections 设置为一个较大的值（maybe 1000~5000?）。那这是否意味着我们不再需要连接池了？答案是否定的，我能想到的两个原因: 应用端大量的短连接频繁创建、删除有性能开销 微服务架构下存在大量应用，相对单体架构需要更多的连接，连接数依然可能耗尽 依据连接池运行的位置可简单将其分为两类，一种是存在于应用程序的 driver 里，如 pgjdbc-ng 库提供的 Connection Pool DataSource；另一种是单独部署的进程。后文介绍的四个连接池都归为第二类。 PgBouncer PgBouncer 是一款轻量的连接池解决方案，单线程、低开销（单个连接占用约 2kB 内存）、使用 libevent 事件驱动库来处理异步 I/O，功能简单，配置容易。 三种使用模式: 会话模式（Session pooling）: 一个客户连接对应一个服务端连接，支持 PostgreSQL 所有特性，常用于多个数据库的连接映射（Connection Mapping） 事务模式（Transaction pooling）: 一个服务器连接只在事务期间分配给客户端。当 PgBouncer 察觉到事务结束时，连接将被放回连接池中。这种模式会破坏几个基于会话的功能 语句模式（Statement pooling）: 不允许多语句事务，意味着 autocommit 必须打开 事务模式不支持的特性有:...

PostgreSQL 是一个对象关系数据库管理系统（object-relational database management system)，如果你看维基百科的定义，ORDBMS 是一种拥有面向对象特性的关系型数据库，对象、类、继承（Inheritance）等概念直接在数据库 schema 和查询语言层面支持。 An object–relational database (ORD), or object–relational database management system (ORDBMS), is a database management system (DBMS) similar to a relational database, but with an object-oriented database model: objects, classes and inheritance are directly supported in database schemas and in the query language. 一定会有人认为 Inheritance 是 PostgreSQL 被称为 ORDBMS 的主要原因，比如 David Johnston(PG contributor) 在 slack 上的回复: 但 PostgreSQL 社区维护的 Don’t Do This 里提示了 Don’t use table inheritance，所以 Inheritance 一定不是 PostgreSQL 称作 ORDBMS 的唯一原因。ChatGPT 给出的答案我认为具有一定参考价值:...

Citus 常用运维命令集。