双语

Reading the internals of Postgres: Database cluster, databases, and tables
22 days ago
- PostgreSQL使用“数据库集群”来指代管理多个数据库的单个实例，而非多个服务器。
- 数据库和其他对象通过OID（无符号整数）标识，用户创建对象的OID从16384开始。
- 像pg_class和pg_database这样的系统目录存储元数据，是可查询的常规表。
- 物理结构以数据目录（$PGDATA）为中心，包含按OID命名的每个数据库的子目录和表。
- 表和索引存储在base/{数据库OID}/{关系文件节点}下的文件中，具有空闲空间和可见性映射的分叉。
- VACUUM FULL可以更改表的relfilenode，使其与OID解耦。
- 表空间允许将数据库对象存储在自定义目录中，在$PGDATA/pg_tblspc/中有符号链接。
- 堆表由包含页头、行指针的8KB页组成，元组从页面末尾开始存储。
- TOAST通过将大值存储在单独的外部表中（分块并索引）来处理它们。
- 写入元组涉及更新页头和行指针，并考虑对齐问题。
- 读取元组可使用顺序扫描或索引扫描（例如B树），具体取决于查询。
Looking Ahead to Postgres 19
21 days ago
- Postgres 19 包含了涵盖应用开发、运维、性能和可扩展性的多项功能。
- REPACK CONCURRENTLY 是一个内置命令，用于无锁回收表膨胀，提升生产数据库的使用体验。
- 分区增强功能允许合并和拆分分区，为适应不断变化的数据工作负载提供了灵活性。
- 逻辑复制现在支持序列同步、发布的 EXCEPT 子句，并通过 effective_wal_level 提供更好的配置。
- 自动清理改进包括并行工作线程、优先级评分系统，以及通过新视图和日志增强的监控。
- SQL 属性图查询 (SQL/PGQ) 允许对关系数据进行图样式查询，无需单独的数据库。
- COPY 命令升级包括跳过多行标题、ON_ERROR SET_NULL 选项，以及更易处理数据工作流的 JSON 输出。
- SQL 易用性功能包括 GROUP BY ALL、窗口函数的 IGNORE NULLS，以及使用 RETURNING 改进的 upsert 行为。
- 性能增强涵盖了规划器优化、反连接、COPY 中的 SIMD 使用，以及更快的外键检查。
- 该版本强调广度，使 Postgres 更适用于多种用户角色和工作负载，并鼓励在正式发布前进行测试。
Commodore 64 Basic for PostgreSQL
18 days ago
- PL/CBMBASIC允许PostgreSQL运行用Commodore 64 BASIC V2编写的函数，使用了编译成C语言的1982年原始解释器。
- 其特点包括代码行号从10开始且必需，函数参数在第0至9行作为BASIC变量注入。
- 包含一个强制C64 BASIC命名规则的验证器，防止变量名包含嵌入式关键字（例如，'TOTAL'包含'TO'）。
- OUT参数的处理方式是在程序执行后从模拟的RAM中读取BASIC变量表。
- 设备8被映射到数据库，允许使用OPEN、INPUT#、PRINT#等命令来执行SQL语句和读取结果。
- 错误通过解释器的ERROR向量捕获，提供PostgreSQL错误的同时附带原始BASIC错误代码。
- 性能基准测试显示，它比PL/Python慢，但比原始硬件快，每次调用有15微秒的重置开销。
- 限制包括仅支持大写字符串、255个字符的字符串长度限制、不支持NULL值，以及仅限超级用户使用的非受信任语言状态。
PostgreSQL and the OOM Killer: Why You Must Use Strict Memory Overcommit
18 days ago
- 严格的过度提交内存策略用于保护PostgreSQL数据库免遭灾难性的OOM终止，将破坏性故障转化为优雅的错误处理。
- PostgreSQL的架构意味着OOM终止可能损坏共享内存，导致连接中断、事务中止和冗长的崩溃恢复过程。
- 一个内核错误（在Linux 6.5版本中引入）导致虚报的内存提交量膨胀，在严格过度提交策略下引发了意外的ENOMEM错误。
- 该错误在Linux 6.8版本中通过修正move_vma()函数中一个导致内存记账错误处理倒置的条件得到修复。
- Ubicloud设置提交限制的经验法则是：物理内存（不包括大页）的80%加上为侧车进程预留的固定2GB缓冲空间。
- 在启用严格过度提交策略前，监控内存使用情况并理解工作负载特性至关重要，以避免频繁的ENOMEM错误。
Tests Are SQL Files Too
17 days ago
- NpgsqlRest 3.12.0 引入了SQL文件作为REST端点，消除了部署和迁移需求。
- NpgsqlRest 3.19.0 通过命名参数、用于实时验证的监视模式以及原生测试运行器增强了此功能。
- 测试运行器使用带有嵌入式HTTP注释的SQL文件进行进程内端点测试，并具有自动回滚以确保隔离性。
- PostgreSQL 的特性，如事务性DDL、可延迟约束和廉价数据库创建，使得数据库测试变得可行。
- 监视模式提供持续验证并在保存时重新运行测试，从而改善开发体验。
- AI TDD（测试驱动开发）通过快速、隔离的测试及为AI代理提供真实反馈循环得以实现。
Show HN: PostgreSQL performance and cost across 23 EC2 instance types
14 days ago
- 根据数据集大小和吞吐量需求选择 AWS 实例；从经过基准测试的实例-磁盘组合中挑选满足要求的最便宜选项。
- 该基准测试的工作负载为 90% 读取和 10% 写入，并发数为 32，在 us-east-1 区域使用 PostgreSQL 17 数据库并按需计费。
- 性能指标包括每秒事务数 (TPS)、延迟和每小时成本；像 c8i.large 和 m8g.large 这样的实例能以较低成本提供较高的 TPS，而 t 系列实例更便宜但性能较差。
Preempt_none Is Dead; Your Postgres Probably Doesn't Care
15 days ago
- AWS基准测试显示，由于移除PREEMPT_NONE抢占模式导致的回归，PostgreSQL在Linux 7.0上的吞吐量降至6.x版本的0.51倍。
- 性能问题源于使用4KB页面和大共享内存（100+ GB）时，自旋锁（buffer_strategy_lock）内的次要页错误，而PREEMPT_LAZY加剧了这一问题。
- 启用大页（huge_pages=on）可通过减少页错误和TLB压力来消除回归，使内核升级对大多数用户安全。
- 自托管服务器应正确配置大页；容器化设置需要主机级大页预留或减少shared_buffers。
- 云数据库用户依赖供应商处理内核和大页配置，无需自行采取行动。
- 内核社区建议使用rseq提供调度器提示，但这并非实用的即时解决方案；PostgreSQL可能在未来的版本中采用它。
- 该基准测试工件强调了正确配置（大页）对于大共享内存工作负载的重要性，而非Linux的根本性问题。
The four horsemen behind Postgres outages
12 days ago
- PostgreSQL 常见故障是由于真空和事务ID回绕造成的，其中删除的行累积，32位ID会导致数据库关闭，如果不回收的话。
- 连接限制和基于进程的并行性导致扩展问题，需要重启或使用像PgBouncer这样的工具，而基于线程的模型在pgrust中提供了一个更安全的替代方案。
- 糟糕的查询计划可能会严重减慢查询速度，并且对规划器的控制有限，不像那些允许提示的数据库；pgrust旨在构建一个自适应查询规划器。
- PostgreSQL中的JSON缺乏统计和压缩功能，导致查询计划效率低下和存储问题；pgrust计划添加真实的统计和压缩功能来解决这个问题。
PgDog (YC P25) Is Hiring a Founding Software Engineer
8 days ago
- PgDog是一家专注于扩展PostgreSQL的初创企业，已获多家公司采用且目前正在招聘。
- 该岗位涉及运用Rust语言、PostgreSQL数据库、基础设施及分布式系统技术，直接为客户构建并交付产品功能。
- 理想的候选人需具备细节导向意识、测试驱动开发习惯、能熟练处理生产环境代码，并能在人工智能辅助与独立思考间取得平衡。
- 职责范围涵盖漏洞修复、功能开发、路线图设计、客户对接以及人才招聘。
- 工作内容包括从零开始使用Rust构建分布式数据库，时间将分配于漏洞修复、新功能开发和基础设施优化三方面。
Why Huge Pages matter for Postgres
6 days ago
- 大页是较大的内存单元（2MB 或 1GB），相比标准的 4KB 页面，它允许一个页表项覆盖更多的内存，从而减少了 CPU 的 TLB 必须缓存的转换次数。
- Postgres 对页面大小很敏感，因为它的 shared_buffers 缓存是由每个后端的页表映射的；使用 4KB 页面时，大型缓存可能会消耗过多的 RAM 用于页表，并导致 TLB 未命中，从而降低读取速度。
- 使用大页（例如 2MB）可以显著减少每个连接的页表内存使用量——在测试中，从每个连接约 31MB 降至约 0.5MB——并提高 TLB 覆盖率，将热点工作集保持在缓存中，从而提升吞吐量。
- ClickHouse Managed Postgres 通过预先保留内存（RAM 的 25%），配置 huge_pages = 'on' 以防止静默回退，并通过测量而非假设来调整 shared_buffers 的大小以适合保留的内存池，从而确保使用大页。
- 在 EC2 实例上的测试显示，使用 200 个连接时，4KB 页面导致 6.12GB 的页表，而使用 2MB 大页时仅为 111MB；由于减少了转换开销，使用大页时吞吐量提高了 12%。
Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table
2 days ago
- PostgreSQL的ADD COLUMN仅将新列添加到末尾，没有'AFTER'子句，这与MySQL不同。这是由于系统目录中的attnum字段所致，该字段为每个列创建时分配一个唯一标识符且永不更改。attnum承担三个角色：作为列的身份标识、磁盘元组中的物理位置以及查询中的逻辑顺序，这使得重新排序变得复杂。删除的列会留下墓碑记录，其attnum槽位不会回收，导致未使用空间直到表被重写。列顺序因数据类型对齐填充影响存储效率；通过'列俄罗斯方块'优化将较宽的列放在首位可节省约20%的磁盘空间。自2014年起，PostgreSQL开发者已提议将attnum拆分为身份、物理和逻辑位置的独立字段，但由于广泛的代码依赖，实施停滞不前。目前，通过ACCESS EXCLUSIVE锁重建表是重新排序列以获取存储增益的唯一方法。MySQL能够轻松处理列重排序，因为它将逻辑和物理列顺序分离，允许在近期版本中无需表重写即可即时添加列。

Hasty Briefsbeta

#postgresql

Reading the internals of Postgres: Database cluster, databases, and tables

Looking Ahead to Postgres 19

Commodore 64 Basic for PostgreSQL

PostgreSQL and the OOM Killer: Why You Must Use Strict Memory Overcommit

Tests Are SQL Files Too

Show HN: PostgreSQL performance and cost across 23 EC2 instance types

Preempt_none Is Dead; Your Postgres Probably Doesn't Care

The four horsemen behind Postgres outages

PgDog (YC P25) Is Hiring a Founding Software Engineer

Why Huge Pages matter for Postgres

Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table