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加速数据库查询。
一直以来都有人问我们，为啥要选择基于PostgreSQL进行产品研发，PostgreSQL相比MySQL在中国的用户群体还比较小，研发出来的产品客户会购买吗？ 为啥不选择MySQL进行研发呢？今天就把咱们团队过去在技术选型上的所思所想通过这篇文章分享给大家。
当需要升级PostgreSQL时，可以使用多种方法。为了避免应用程序停机，不是所有升级postgres的方法都适合,如果避免停机是必须的，那么可以考虑使用复制作为升级方法，并且根据方案，可以选择使用逻辑复制或物理（流）复制来处理此任务。我们来看看PostgreSQL中逻辑和物理复制之间的区别。然后，我们将更详细地探讨如何使用逻辑复制完成升级，并通过这样做，避免应用程序停机。在后面的文章中，我们将研究物理复制。我们已经在之前的系列文章中讨论了几种可用于升级或迁移旧版PostgreSQL到新版PostgreSQL版本的方法,使用pg_dumpall进行PostgreSQL升级和使用pg_dump/pg_restore进行PostgreSQL升级。但是,这两种方法都涉及到应用程序的停机时间。
本文通过与Oracle隐式类型转换的比较简要介绍了PostgreSQL中的隐式类型转换，包括Oracle隐式类型转换的机制、PostgreSQL隐式类型转换的机制和原理。
PG是一款开源的关系型数据库，在过去30年中，其流行度从其活跃、忠诚且持续成长的社区中迅速飙升。根据DB-Engines的专家们给出的《DBMS of the Year》报告，PG已经连续两年蝉联世界“成长”最快数据库的名号。那么，是什么让PG如此出众，当今它又是如何被应用于实际生产？！我们在3月举行的Postgres Conference会议中找到了答案，在那里，我们采访了许多PG的用户、贡献者以及SQL/NOSQL数据库管理员。
SQL 全名是结构化查询语言（Structured Query Language），是用于数据库中的标准数据查询语言。传统来讲，SQL 语言分为三个部分：