《PostgreSQL 设计优化case - 大宽表任意字段组合查询索引如何选择(btree, gin, rum) - (含单个索引列数超过32列的方法)》 https://github.com/digoal/blog/blob/master/201808/20180803_01.md 《PostgreSQL 任意字段数组合 AND\OR 条件，指定返回结果条数，构造测试数据算法举例》 https://github.com/digoal/blog/blob/master/201809/20180905_03.md 《PostgreSQL ADHoc(任意字段组合)查询(rums索引加速) - 非字典化，普通、数组等组合字段生成新数组》

并发控制是多个事务在并发运行时，数据库保证事务一致性（Consistency）和隔离性（Isolation）的一种机制。主流商用关系数据库使用的并发控制技术主要有三种：严格两阶段封锁（S2PL）、多版本并发控制（MVCC）和乐观并发控制（OCC）。

背景 预测营收目标，预测KPI风险。使用PostgreSQL二维线性回归，更高级一点可以使用MADLIB多维线性回归。 预测方法： 例如有最近连续4周的营收数据，预测第一季度，第二季度，第三季度，第四季度的营收。 例如设定了财年的营收目标，有最近连续四周的营收完成比率，预测第一季度，第二季度，第三季度，第四季度的营收完成率。

前几天一位社区朋友咨询一个PostgreSQL的WAL文件膨胀案例，有个生产库最近几天pg_wal目录的WAL文件爆涨到了7万多个，把硬盘空间撑满，造成数据库故障。 为了快速恢复，这位朋友删除了pg_wal目录下10天前的WAL文件，将硬盘空间使用率降下来，使得数据库恢复，但pg_wal目录下的WAL文件依然涨得很快。

并发控制是多个事务在并发运行时，数据库保证事务一致性（Consistency）和隔离性（Isolation）的一种机制。主流商用关系数据库使用的并发控制技术主要有三种：严格两阶段封锁（S2PL）、多版本并发控制（MVCC）和乐观并发控制（OCC）。 PostgreSQL使用了多版本并发控制技术的一种变体：快照隔离Sanpshot Isolation（简称SI）。通过SI，PostgreSQL提供了四个事务隔离级别，但实现与ANSI SQL标准有一些差异。

PostgreSQL heap TABLE AM引擎，使用多版本来解决快照问题，版本处于当前数据文件中，有垃圾回收进程进行回收，那么哪些垃圾不能被回收呢？ WAL是PG的REDO文件，哪些WAL不能被回收重复利用？什么情况下可能会一直增长不清理呢？

背景 PostgreSQL heap TABLE AM引擎，使用多版本来解决快照问题，版本处于当前数据文件中，有垃圾回收进程进行回收，那么哪些垃圾不能被回收呢？ WAL是PG的REDO文件，哪些WAL不能被回收重复利用？什么情况下可能会一直增长不清理呢？ heap或INDEX的膨胀有些时候并不是因为回收慢，而是有些是无法被回收的垃圾，通常被称为膨胀点。本文对膨胀点进行逐一解释(回收慢不解释，可能: worker太少,io太差,worker睡眠太长或频繁,vacuum mem太少放不下所有垃圾行CTID导致多次扫描索引,launcher唤醒周期太长,表太大未支持并行垃圾回收, …)。 除了snapshot too old以外，12新增AM例如zedstore, zheap将彻底解决heap的垃圾版本带来的膨胀问题。

PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。关系（表与索引）膨胀会对数据库性能产生负面影响，并浪费磁盘空间。为了使PostgreSQL始终保持在最佳性能，有必要及时对膨胀的关系进行垃圾回收，并定期重建过度膨胀的关系。

已有分区表，修改分区的范围。 例如拆分分区，合并分区。 语法如下，PG支持非常灵活的分区布局，看本文提到的HASH分区拆分，支持任意层级的分区，支持每个分区的层级深度不一样。特别适合某些数据分布不均匀的情况。例如id=1落在同一个分区但是数据量非常庞大，可以对这个分区再进行二级分区（使用其他分区方法，其他字段都可以，非常灵活）。

pg_cron 是 PostgreSQL（9.5或更高版本）的一个简单的基于cron的作业调度程序，它作为扩展在数据库中运行。它与常规 cron 保持相同的语法，但它允许直接从数据库安排 PostgreSQL 命令。作为一个独立运行的工作者进程，其生命周期管理、内存空间都依赖于 postgreSQL 。本文主要从启动、生命周期、状态机、用法介绍该插件在 postgresQL 数据库中的应用。

知识的学习是越学越不会,越学发现的"黑洞"和自己的欠缺就会越多,所以一直报以心虚的状态来学,可能理解多年的东西他变化了,或者当初就没有理解的彻底,而不自知. Pgbouncer 看似是一个轻量级的连接缓冲,今天就来整理一下,来看看知识的黑洞

接上期为什么postgresql 需要连接池的问题过后, 本期还是要说说pgbouncer 连接池,并且需要做一个实验看看pgbouncer 到底在处理并发连接到底有多大的功效.

估计很多同学看过之前的月报PgSQL · 特性分析· JIT 在数据仓库中的应用价值，对JIT（just in time）和LLVM（Low Level Virtual Machine）有了一定的了解。概括地来说： JIT 指的是即时编译，即程序在运行过程中即时进行编译，其中可以把编译的中间代码缓存或者优化。相对于静态编译代码，即时编译的代码可以处理延迟绑定并增强安全性。 LLVM 就提供了一种在程序运行时编译执行代码的程序框架，它对外提供API，使实现JIT 变得更加简单。 PostgreSQL 社区从2016年就开始对JIT 的实现进行了讨论，详见邮件列表。

背景 PostgreSQL 有3种停库模式： “Smart” mode waits for all active clients to disconnect and any online backup to finish. If the server is in hot standby, recovery and streaming replication will be terminated once all clients have disconnected.

每当开发完一个新的功能后，要想让其稳定的上线的前提是必须完成回归测试，回归测试定义为一种软件测试，用于确认最近的程序或代码更改未对现有功能产生负面影响。回归测试只不过是已经执行的测试用例的全部或部分选择，这些测试用例被重新执行以确保现有功能正常工作。对于最先进的开源数据库Postgresql当然也提供了它的回归测试。我们在官方文档中可以找到其具体的使用方法。

Greenplum 是一款开源MPP数据分析平台，提供包括数据分析、机器学习和人工智能等特色功能。目前 Greenplum 的二进制发行版本只能运行在 X86 服务器。github上的Greenplum releases只有x86的发行版，没有提供ARM 发行版。Greenplum 是开源软件，我们可以通过编译 Greenplum 源代码自行构建 Greenplum 的 ARM 版本。

背景 当有写IO等待问题时，有一些调整参数的方法可以像打了鸡血一样提速，但是安全性如何？ 1 危险系数最高 关闭fsync。本该持久化同步写的(例如checkpoint，wal write)变成了异步，可能丢数据，同时会导致数据库的数据不一致，极度危险。 任何时候都不建议关闭fsync。

在数据库的运行过程中，难免会遇到各种非预期的问题，例如： 硬件错误，例如突然断电、磁盘错误、有人拔了你的内存条 :P 软件问题，例如操作系统崩溃、数据库内部存在bug等等 操作错误，例如误删数据、插入了不符合预期的数据、应用程序异常等等 … … 在这些情况下，我们不希望我们的数据异常甚至丢失，有的情况下我们不能进行修复，例如火灾（这类问题依赖于备份存储介质的方式解决，需要异地容灾），但有的情况下我们可以进行解决，例如断电、崩溃。我们希望当数据库重新启动时，能够恢复其崩溃的那一瞬间的状态，能够恢复出“一致的”、“完整的”数据。

PostgreSQL 13 的逻辑复制新增了对分区表的支持，使得分区表也能够进行逻辑复制。

PostgreSQL的Slogan是“世界上最先进的开源关系型数据库”，但我觉得这口号不够清晰，啥叫‘先进’？而且一看就是在怼MySQL那个“世界上最流行的开源关系型数据库”的口号，有碰瓷之嫌。要我说最能生动体现PG特色的描述应该是：一专多长的全栈数据库，一招鲜吃遍天。