Japin

PostgreSQL 支持不同级别的参数配置，最简单的是全局配置，此外还有针对用户级别和数据库级别的配置，本文就来看看 PostgreSQL 中用户级别和数据库级别的配置的实现。

我们可以实现下面的 SQL 命令来修改用户级别的配置：

1
2
3
4

ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter FROM CURRENT
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] RESET configuration_parameter
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] RESET ALL

从上面的语法可以看出 PostgreSQL 配置的灵活性，您可以针对某个用户进行配置，也可以针对某个用户连接某个数据库进行配置。

数据库级别的配置相对于用户级别来说就要简单一些了，如下所示：

1
2
3
4

ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter FROM CURRENT
ALTER DATABASE name RESET configuration_parameter
ALTER DATABASE name RESET ALL

PostgreSQL 数据库大部分操作都依赖于系统表，因此为了加速访问，PostgreSQL 针对系统表提供了两种缓存：RelCache 和 SysCache。RelCache 和 SysCache 都是进程本地的，每个 backend 进程启动的时候都将创建自己的 RelCache 和 SysCache。本文将简要介绍一下这两类缓存。

• RelCache 用于缓存表的 RelationData 结构（关系描述符 - reldesc），该结构由系统表中的元组构成。
• SysCache 用于缓存系统表的元组信息。

在使用 pg_backtrace 插件时，必须执行 SELECT pg_backtrace_init();，不执行该函数插件就不生效，官方文档也特别说明了，而实际上该函数是一个空函数，为什么必须要执行该函数才生效呢？

这是一个朋友问我关于 pg_backtrace 的问题，这主要涉及到 PostgreSQL 中动态库的加载过程。本文在分析问题的基础之上，简要梳理一下 PostgreSQL 中动态库的加载过程。

今天在邮件列表中发现一个关于 psql 内存泄露的问题，经过测试，确实存在内存泄露。同时，我在查看周围的代码时，还发现其它地方也存在类似的内存泄漏。本文简要记录一下该问题。

PostgreSQL 的 repeat() 函数用于重复生成给定的字符串。例如：

1

repeat('abc', 3) -> 'abcabcabc'

最近在使用这个方法来生成 1GB 的数据时，遇到了一点问题。如下所示：

1
2

postgres=# CREATE TABLE myrepeat AS SELECT repeat('a', 1024 * 1024 * 1024);
ERROR:  invalid memory alloc request size 1073741828

在之前的文章中，我们讨论了系统如何规划查询以及如何收集统计信息以选择最佳执行计划。从这篇文章开始，后续的文章将终点关注计划的本质、它的组成以及如何执行。

在本文中，我将演示规划器如何计算执行成本。我还将讨论访问方法（Access Methods）以及它们如何影响这些成本，并使用顺序扫描方法作为说明。最后，我将谈谈 PostgreSQL 中的并行执行的工作原理以及何时使用它。

我将在本文后面使用几个看似复杂的数学公式。您无需记住任何一个公式也可以理解规划器是如何工作的；它们只是为了显示我的数据来源。

继浮点数溢出问题和汇编指令操作数越界问题之后，我又发现申威平台上一个关于 LLVM 的问题，这个直接导致数据库进程崩溃了，本文简要记录一下这个问题（之前反馈的问题到现在还没有得到回复 :( ，估计是太忙了吧），目前这个问题同样反馈给申威相关的人员了，期待能尽快得到解决。

MERGE INTO 语法很早之前就在 Oracle 数据库中实现了，最近 PostgreSQL 也实现了相应的语法，该语法符合 SQL2016 标准，与 Oracle 的 MERGE INTO 还是有一定区别的。本文简要介绍一下 PostgreSQL 中的 MERGE INTO 语法。

PostgreSQL 主分支中针对 pg_waldump 新增了四类过滤选项，分别为 RelFileNode、BlockNumber、ForkNum 和 FPW。本文将简要介绍一下这四个过滤选项。

尽管不幸的事仍在发生^[1]，但我们还是需要继续这个系列。在上一篇文章中，我们回顾了查询执行的各个阶段。在我们继续计划节点操作（数据访问和连接方法）之前，我们需要了解成本优化器的基本要素：统计信息。

和往常一样，我所有的例子都使用演示数据库。您可以下载并跟着一起执行。

今天您会在这里看到很多执行计划。我们将在以后的文章中更详细地讨论这些计划是如何运作的。现在只需注意您在每个计划的第一行中看到的数字，在单词 rows 旁边。这些是行数估计值或基数。