上篇介绍容器相关的基本概念，介绍如何安装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 语言分为三个部分：

在开发项目过程中，客户要求使用gbase8s数据库(基于informix)，简单的分页页面响应很慢。排查发现分页sql是先查询出数据在外面套一层后再取多少条，如果去掉嵌套的一层，直接获取则很快。日常使用中postgresql并没有这样的操作也很快，这是为什么呢？

EcoX数据库高可用集群管理系统软件，该软件包含数据库高可用、读写分离、负载均衡、连接池等功能，能够保证业务7*24小时连续运行，保证数据零丢失。 在上期我们已经介绍过如何全新搭建一个EcoX-PostgreSQL高可用系统，期间有很多用户咨询对于已有集群，用ECOX如何接管，所以这期我们介绍如何用ECOX集群管理系统对一个已有的PostgreSQL流复制集群进行高可用改造。

许多领域需要大规模模式匹配以实现各种计算目标。匹配模式的细节变化很大，从索引到修剪到强力匹配。可扩展性通常是一个问题，因为内容和模式数据库越来越大，变成了TB级。这种增长受许多因素驱动，例如增加的数据库成员（例如，图像数量）以及越来越多的测量和测量编码大小。

EcoX数据库高可用集群管理系统软件，该软件包含数据库高可用、读写分离、负载均衡、连接池等功能，能够保证业务7*24小时连续运行，保护业务最大可用性。其特点如下： 基于可靠的ZAB协议传递消息和控制指令，确保系统准确无误运行和执行指定的命令。 采用集群仲裁机制，防止单点故障和误操作。 单套ECOX集群能够管理成百上千个PostgreSQL集群，帮助企业和运维人员提高效率，简化运维难度。

如果是之前学习别的数据库的人，看PostgreSQL会感觉到有句话非常奇怪：“PostgreSQL的回滚是立即完成的，不会受到事务大小本身的影响”。

数据库在本质上是一个状态集合，任何对数据库的变更（增删改）本质上都是对状态的修改。 在实际生产中，我们经常需要把数据库的状态同步到其他地方去，例如同步到数据仓库进行分析，同步到消息队列供下游消费，同步到缓存以加速查询。总的来说，搬运状态有两大类方法：ETL与CDC。

作者简介： 帅宇，资深DBA，从事Oracle数据库管理和SQL开发超过15年，3年+PG数据库开发经验，擅长数据库建模设计，SQL开发，SQL性能调优。现就职于平安科技数据库技术部，云数据库架构师，负责平安云数据库产品配置管理系统设计和后台SQL开发。 1.RDS的图之尴尬 图是一种应用广泛但比较复杂的数据结构。但传统的关系型数据库很难处理图的一些问题，例如求最短路径。让我们看一个简单的例子：

众所周知，当创建一个新的索引之后，数据的修改操作会变慢并且该索引会占据一定的磁盘存储空间，这是我们创建一个新索引必须付出的代价。这也是为什么你需要尝试没有创建多余索引的原因。

PostgreSQL的堆表由多个页组成。业内结构如上图所示(代码readme中)，由5部分构成，如下。 模块 描述 页头 24字节长，包含页内的总体信息与空闲空间的位置。 行指针 每个行指针占4个字节，由两项信息构成(offset,length) ，指向实际的Tuple数据。 空闲空间 页内未分配的空间，如果FreeSpace剩下的空间放不下一个元组，那么该页就是满了。新的行指针从空闲空间的头部开始分配，相应的Tuple数据从空闲空间的尾部开始分配。 Tuple 实际的Tuple数据 特殊空间 如果是索引页，那么根据索引类型的不同存储的数据也不同。