1. 背景 PostgreSQL的HA方案一般都基于其原生的流复制技术，支持同步复制和异步复制模式。 同步复制模式虽然可以最大程度保证数据不丢失，但通常需要至少部署三台机器，确保有两台以上的备节点。 因此很多一主一备HA集群，都是使用异步复制。 在异步复制下，主库宕机，把备节点切换为新的主节点后，可能会丢失最近更新的少量数据。 如果这些丢失的数据对业务比较重要，那么，能不能从数据库里找回来呢? 下面就介绍找回这些数据的方法

最近，在排查PostgreSQL性能问题的时候，两次遇到子事务相关问题。所以，我想这个话题非常适合作为博客内容。

Postgresql由于强大的功能和良好的扩展性，基于postgresql来做的分布式架构也比较多，大部分用于分析类场景，下面比较几种常见的架构特点。

笔者前段时间在写一个个人自用的项目时候，遇到一个需求，要从一个6百多万数量的表中，使用like ‘%keyword%’这种语法来找到需要的结果,虽然默认情况下，也不是不能接受（SSD存储+并行查询让这个事情实际的执行效率比想象中高得多），但毕竟对资源的瞬间消耗很大，让家里的小NAS有点不堪重负，因此对PostgreSQL对like的处理上，进行了诸多调查，来让这个事情的处理，可以看起来更漂亮些。

人脸识别, 人脸支付, 刷脸打卡, 图像识别等 例如, 智能楼宇, 根据人脸识别到是本大楼的员工时, 自动进行打卡, 自动按工作楼层设定电梯. 智能酒店, 根据人脸识别, 自动入住, 根据会员等级自动对接专属服务等等. 电商, 图像识别, 搜索类似商品. 教育, 根据人脸特征, 记录学生的听课状态(打盹, 走神, 小动作, 举手等) 交通, 违规时自动识别驾驶员. 新零售, 根据人脸识别对应后台的会员系统, 做到: 到店提醒, 导购引导, 定制化运营等. 公共交通, 刷脸支付. 游戏, 虚拟现实相关游戏.

PostgreSQL新版本即将发布，因此是时候看看PostgreSQL11提供的最重要新功能之一：并行创建索引（注：原博客发表于2018年）。多年以来，各种商业数据库供应商已经提供该功能，因此很高兴PostgreSQL成为该精英俱乐部的一员，它提供了多核索引创建能力，这将极大的改善大型数据库部署的可用性。

在PostgresSQL9.6中引入了并行查询，从那之后这一功能不断地得到扩展。在PostgreSQL11和PostgreSQL12中，数据库引擎增加了更多的功能。然而，仍然有一些与并行查询相关的问题，这些问题经常出现在培训过程中，因此有必要澄清说明一下。

根据目标群体的特征, 快速提取目标群体. 例如, 在电商行业中, 商家在搞运营活动前, 根据活动的目标群体的特征, 圈选出一批目标用户进行广告推送或活动条件的命中. 在游戏行业中, 运营经常会根据游戏玩家的某些特征圈选, 针对性的发放大礼包, 激活游戏活跃度. 在教育行业中, 根据学生不同的特征, 推送不同的有针对性的习题, 提升学生的弱项. 在搜索、门户、视频网站等业务中, 根据用户的关注热点, 近期行为的不同, 根据群体推送内容.

2020疫情无情，诸多企业因此受挫，特别中小企业，甚至到了要裁员的地步, 但是人才是最宝贵的，裁员一定是下下策，如何渡过这个难关，疫情带给我们什么反思? 开源节流有新方法，通常数据库在企业IT支出中的占比将近一半，降低数据库成本对降低企业IT成本效果明显，但是一般企业没有专业DBA，很难在这方面下手，不过没关系，有了云厂商，一切变得简单。借助阿里云我们找到了可以为企业IT节省至少一倍成本的方法.

本文详细讲解了把fillfactor参数调整到70%时，使用csd2000的透明压缩功能让实际占用空间很少增长的情况下（增长8%），让pgbench测试出来的性能提升近40%。同时使用了csd2000的透明压缩功能让空间占用率到达了原空间的六分之一，大大的节省了空间。

Oracle DBA都知道，绑定变量窥视功能是Oracle数据库的一个特性，自ORACLE9i版本开始引入，是可以通过参数数“_optim_peek_user_binds”来控制是否开启，默认是开启，即为TRUE。这就意味着，第一次以变量的方式执行某类SQL时，会生成第一个执行计划，后续执行该类SQL语句，即使变量的传入值不同，但因变量窥视的作用，依然会沿用第一次SQL语句执行时生成的执行计划，这种特性非常适用于业务表数据分布比较均匀的场景，执行计划比较稳定。但对于数据分布严重倾斜的业务表，可能会出现错误的执行计划，在极端情况下，会引发严重的性能问题。

本文介绍了PostgreSQL的Autovacuum机制中容易出现误解的地方，包括Autovacuum的调度机制、Autovacuum的监控以及相关的数据字典和数据库参数等。

版本号－－V2.17 更新日期：2019-11-13

我们知道postgresql数据库通过数据多版本实现mvcc，pg又没有undo段，老版本的数据元组直接存放在数据页面中，这样带来的问题就是旧元组需要不断地进行清理以释放空间，这也是数据库膨胀的根本原因。本文简单介绍一下postgresql数据库的元组、页面的结构以及索引查找流程。

版本号－－V2.17 更新日期：2019-11-13

TBase是一个提供写可靠性，多主节点数据同步的关系数据库集群平台。你可以将TBase配置一台或者 多台主机上，TBase数据存储在多台物理主机上面。数据表的存储有两种方式， 分别是distributed或者replicated ，当向TBase发送查询 SQL时，TBase会自动向数据节点发出查询语句并获取最终结果。

我们知道mysql没有hash join，也没有merge join，所以在连接的时候只有一种算法nest loop join，nl join使用驱动表的结果集作为外表到内表中查找每一条记录，如果有索引，就会走索引扫描，没有索引就会全表扫。

PostgreSQL 12，“世界上最先进的开源关系型数据库”的最新版本，如果没有其他问题，将在接下来的几周时间内正式发布。该项目每年新增大量新数据库功能，坦白地说，这一点非常令人惊讶。同时也是我参与PostgreSQL社区的主要原因之一。

PostgreSQL 的分区表个人认为是 PostgreSQL 比较薄弱的环节，老版本的分区表通过继承表和触发器实现，甚至需要逐个对子表进行索引创建，使用上不方便。 10 版本和 11 版本在分区表的功能上进行了大幅完善，但是当分区表分区数量较大时，分区表的DML性能并不好。 PostgreSQL 12 版本的分区表的性能得到了大辐提升，尤其当分区表的分区数量非常多时，DML 性能提升更加明显。

像微软的SQL Server，IBM的DB2，包括从11发行版本开始的PostgreSQL数据库，在创建索引的语句中都支持include子句。介绍PostgreSQL中的这个特性是我写这篇长文介绍include子句的主要目的。 在详细介绍之前，让我们先简单回顾下（非聚集）B树索引的工作原理以及强大的仅索引扫描（index-only scan）。