我们知道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）。
接前一篇文章，这里继续介绍在工作中遇到的一个死锁案例。经过对业务模型的抽取分析（后面会介绍表结构和数据，业务模型来源于开源组件的实际业务），模拟得到的死锁日志信息如下：
对于IP地址段查询的场景，PostgreSQL的ip4r插件是一个性能和通用性都比较不错的一个方案，但用户不一定方便使用ip4r，比如在未安装ip4r的公有云RDS上或者使用PostgreSQL以外的数据库
PostgreSQL 的 CTE( common table expressions ) 支持较复杂的查询，比如递归查询等场景， 12 版本之前 CTE 的 WITH 语句都是直接物化的，也就是说 WITH 语句执行一次并保持到一个类似的临时表中，供 WITH 语句外层的SQL引用，当 INSERT/UPDATE/DELETE 做CTE的 WITH 语句时是非常恰当的。
随着传感技术的发展，关系数据库的重要性不断增加。大型天气测量望远镜（LSST）每晚产生20TB，大型强子对撞机（LHC）每年产生30PB的数据。 Google和Facebook等社交网络公司每天都会收集大量人为生成的数据。
随着传感技术的发展，关系数据库的重要性不断增加。大型天气测量望远镜（LSST）每晚产生20TB，大型强子对撞机（LHC）每年产生30PB的数据。 Google和Facebook等社交网络公司每天都会收集大量人为生成的数据。
在最近的生产环境巡检中，发现一个死锁错误。从日志中看，触发死锁的是对表的相同行操作，最终分析和业务操作有关，不过其中涉及到Postgres数据库的外键更新加锁处理逻辑，下面对这个问题展开详细分析。
在学习完第一篇《Docker与PostgreSQL 11.5系列文章（一）Docker的安装》和第二篇《Docker与PostgreSQL 11.5系列文章（二）postgreSQL 11.5安装》之后，继续讨论容器的持久化。“持久化” 简单理解，就是容器被关闭后PostgreSQL数据库的数据是否还存在？
上篇介绍容器相关的基本概念，介绍如何安装docker。如果不熟悉docker的安装，可回到系列文章的第一部分《Docker与PostgreSQL 11.5系列文章（一）Docker的安装》。第二部分主要介绍PostgreSQL11在容器中的安装和使用。
Docker前几年席卷了整个互联网，Docker在互联网很多业务场景都有使用。最近一两年，一些传统行业也在尝试使用，并且看到不少案例。另外，我们一直担心，容器影响数据库的性能，根据近些年的亲身实践，容器对数据库性能的影响很小，也不会影响数据库的并行性。因此，想写一系列文章，简单介绍PostgreSQL在容器中的实践。
GPUDirect RDMA允许直接从PCIe设备到GPU RAM的对等数据加载。对于Linux内核和PostgreSQL的扩展模块，我们通过将NVMe-SSD上的数据库块加载到GPU RAM以及在GPU设备上执行SQL来协同利用此基础架构进行非常快速的表扫描。一旦数据块加载到GPU RAM上，内核函数就会根据提供的SQL（WHERE clause，JOIN和GROUP BY）减少数据大小。在结果中，CPU / RAM将获得比实际表大小小得多的数据大小，并且看起来存储在理解SQL的情况下智能地执行。根据基于SQL星型模式的基准测试，我们的功能可以在80秒内扫描351GB平台;这是大约4.5GB / s的查询处理吞吐量，比通常的文件系统基本I / O实现快2.5倍。此结果表明GPU对I / O密集型工作负载也很有价值，而不仅仅是计算密集型工作负载。
PostgreSQL 之前版本已支持 Json 和 Jsonb 数据类型，支持非关系数据的存储和检索，如果 Json 数据较复杂(层级多、嵌套json、包含数组等 )，之前版本不能方便的检索 Json 数据元素值。 PostgreSQL 12 版本的一个重量级特性是新增 SQL/JSON path 特性，支持基于 Json 元素的复杂查询，文档上关于 SQL/JSON path 内容很丰富，本文仅演示简单的用例。
Postgresql 11.2版本物理复制，startup 进程命令行有时会出现waiting 标识。本文分析了出现waiting 标识的原因。
在OpenShift 3.9 GPU博客中，我们利用OpenShift上的机器学习框架进行图像识别。在OpenShift 3.10博客中的如何使用带有DevicePlugin的GPU中，我们安装并配置了支持GPU的OpenShift集群。在本部分中，我们将在集群上创建更复杂的工作负载-使用GPU加速数据库查询。