探讨使用火山引擎云数据库PostgreSQL版与大语言模型LLM，实现企业智能交互式问答系统，介绍其原理与向量化存储检索技术。

This blog post describes a recent contribution from Zalando to the Postgres JDBC driver to address a long-standing issue with the driver’s integration with Postgres’ logical replication that resulted in runaway Write-Ahead Log (WAL) growth. We will describe the issue, how it affected us at Zalando, and detail the fix made upstream in the JDBC driver that fixes the issue for Debezium and all other clients of the Postgres JDBC driver.

数据库将SQL解析成一棵语法树后，就需要将语法树转换成查询树，然而查询树的每一个节点或者节点之间的连接都会有一种或者多种实现算法，而需要从中挑选出最优的节点组合。

路径表示单个表的访问方式(顺序访问、索引访问、点查)、两个表的连接方式(嵌套连接、归并连接、hash连接)以及多个表的连接顺序。 那么优化器需要枚举出所有的路径，从中挑选代价最低的路径来执行。

查询树上有的节点是可以直接进行优化的，如过滤、投影等，在查询树底部先将不需要的数据过滤掉，以减少数据量往查询树上层的传递以及操作的成本，这种优化是显而易见的，是基于经验的，我们称为启发式规则优化。 然而，有的优化是无法直接进行的，例如，A JOIN B，JOIN顺序A JOIN B 或者 B JOIN A都会输出正确的查询树结果，哪种顺序成本最低呢，这就需要基于统计数据来进行估算，找出代价最小的顺序，这种优化我们称之为基于成本的优化。

在数字化时代的今天，我们都认同数据会创造价值。为了最大化数据的价值，我们不停的建立着数据迁移的管道，从同构到异构，从关系型到非关系型，从云下到云上，从数仓到数据湖，试图在各种场景挖掘数据的价值。而在这纵横交错的数据网络中，逻辑复制扮演着极其重要的角色。

让我们将视角从复杂的网络拉回其中的一个端点，从PostgreSQL出发，对其逻辑复制的原理进行解密。

在地图或地理信息有关的场景里，地址关键词的检索尤其重要。比如打开百度地图，想要查询某个位置的信息“北京市海淀区清华东路17号中国农业大学”，往往我们输入的是关键词“中国农业大学”而不是精确到街道的详细地址信息。在地址关键词检索的背后，需要的是一款可以支持全文检索和模糊查询的数据库与之匹配，以此快速提高地址检索的效率。

经常有这样的 case ，业务线开发同学需要 DBA 帮助其在不同的 PostgreSQL 数据库或集群之间同步数据。

数据量较小时，使用 pg_dump 工具或 copy 命令即可完成同步需求。但当数据量较大时，直接同步数据容易引发源 DB 或目标 DB 出现 slow query 或主从同步延迟等问题，容易对数据库的性能及稳定性造成不良影响。

而且无论数据量大小与否，有时候手工或写定时任务同步数据都很容易出错，且目标DB的数据如果恰好有人在使用极易与同步数据的任务相互阻塞。

是否存在其他数据同步方案避免上述问题呢？通过调研加实践，PostgreSQL中运用FDW与Materialized View可以较好的优化上述问题。

从数据库内核的角度揭秘TDSQL-C PostgreSQL的核心架构与关键技术。

一道 Sequence 的“开水白菜”，敬请“享用”。

一个表的数据量达到一定程度后，稳定性和性能就会出现瓶颈，"化整为零"对DBA 来说无疑是一个很好的选择，此时如何分表就成为摆在业务线开发同学和 DBA 面前的一道不可回避的课题。

相对于传统的开发同学自己根据业务及自己在应用代码中实现分表的方案，本文介绍一下 PostgreSQL 中如何实现对业务相对透明的分区方案。

PostgreSQL是一个功能非常强大的、源代码开放的客户/服务器关系型数据库管理系统（RDBMS），PostgreSQL被业界誉为“先进的开源数据库”，支持NoSQL数据类型（JSON/XML/hstore），主要面向企业复杂查询SQL的OLTP业务场景，提供PostGIS地理信息引擎、阿里云自研多维多模时空信息引擎等。

本文着重介绍PostgreSQL的数据目录，其中保存着配置文件、数据文件、事务日志和WAL日志等重要文件，所有客户创建的数据文件和初始配置文件都可以在数据目录中找到，因此数据目录是重要的客户价值所在。

Re-ordering table columns to avoid wasting space for data type alignment.

Braintree Payments uses PostgreSQL as its primary datastore. We rely heavily on the data safety and consistency guarantees a traditional relational database offers us, but these guarantees come with certain operational difficulties. To make things even more interesting, we allow zero scheduled functional downtime for our main payments processing services.

DBA 经常需要排查某一个事务中有哪些 SQL 的场景。典型的 case 就是 DB 有一个 lock 报警，从系统表中查看发现是1个 update 等待的 SQL 是1个 select。熟悉 PostgreSQL 的同学都知道：在 PostgreSQL 中，由于特有的 MVCC 机制，读不阻塞写，写不堵塞读。

那么为什么会产生这种 lock？

实际就是因为这个 select 处于一个事务中，事务中有其他 update/delete 等写入操作持有后面的其他事务中的 update 操作所需要的 lock。此时就需要到 DB log 去排查这个 select 所处的事务的完整的全部 SQL，反馈给业务线的开发同学，以便于进一步优化。

最近有业务线的同学向 DBA 提出这样的需求:“我的表里有很多敏感数据，怎么给使用者(从 DBA 角度来看就是 DB User)指定查看某些特定行或某些列的权限？”

这是我们经常用到的业务场景，比如最典型全公司的短信数据和用户管理平台场景，如何限制各部门仅可查看属于本部门的某些非敏感数据？

PostgreSQL 为了符合各种场景的安全需求，它的权限控制非常完善，它在各个级别上都具有广泛的安全功能。接下来我们来看一下在 PostgreSQL 中利用行级安全和列级安全来解决上述问题。

Everything about database,business.(Most for PostgreSQL). - blog/20170521_01.md at master · digoal/blog