Patroni 是一个用于管理 PostgreSQL 高可用性的开源工具。它基于 etcd、ZooKeeper 或 Consul 作为分布式一致性存储，以提供自动故障转移和集群管理功能。

默认情况下track_io_timing参数是关闭的，所以“读数据块的总时间”和“写数据块的总时间”这两项没有数据。这里需要重点关注swap大类中的si和so，如果这两项中有大于0的数值，说明发生了SWAP交换，系统的内存不足了。各CPU共享相同的物理内存，访问内存任何地址所需的时间相同，因此程序设计较为简单。·优点：多CPU模块，每个CPU模块具有独立的本地内存（快），但访问其他CPU内存（慢）

在 PostgreSQL 的世界里，索引从来不是“有没有”的问题，而是“值不值”的问题。随着 PostgreSQL 近几个大版本（12 → 17）的持续演进，索引相关的优化逐渐从“单点能力增强”，转向“在有限资源约束下的整体效率提升”，如PG14的索引去重、PG16的多列综合评估等。虽然内核上对于多列索引的算法做了很多优化，但是其索引顺序依然会对SQL的检索性能产生较大影响。

最近开发在springt ORM框架下遇到一个以下报错信息。我做了一个复现SQL就是简单的查询，采用了预备语句的绑定变量。

默认情况下track_io_timing参数是关闭的，所以“读数据块的总时间”和“写数据块的总时间”这两项没有数据。这里需要重点关注swap大类中的si和so，如果这两项中有大于0的数值，说明发生了SWAP交换，系统的内存不足了。各CPU共享相同的物理内存，访问内存任何地址所需的时间相同，因此程序设计较为简单。·优点：多CPU模块，每个CPU模块具有独立的本地内存（快），但访问其他CPU内存（慢）

摘要： 文章探讨了PostgreSQL中EXPLAIN ANALYZE与直接执行SQL存在10倍性能差异的问题。通过auto_explain模块分析发现，差异源于并行执行计划是否启用：EXPLAIN ANALYZE成功启动8个并行工作进程（Workers Launched=8），而直接执行时并行工作组未激活（Workers Launched=0），导致单线程扫描效率大幅下降。进一步排查排除了参数配

在数据库中进行增删改查比较常见，经常会用到update的使用。但是在近期发现update在oracle和postgresql使用却有一些隐形区别，oracle 在执行update语句的时候set 后面必须跟着1对1的数据关联而postgresql数据库却可以一对多，这就导致数据在被新的时候出现不确定性。