进行了请教与沟通。以上都只是冰山一角，更多内容请各位读者自行发掘。纸质版的发售另外各位读者可能关心的便是纸质版了，纸质版相较于电子版就要麻烦一些，这也是为什么我会选择电子版

----------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

前言前年的时候曾分享过一次PostgreSQL相关优质书籍的推荐，现已2024年，期间也阅读了不少优质书籍，再次推荐一下~第二弹！书籍推荐首先是之前推荐过的📚：《PostgreSQL小工到专家》：唐成老师著，也是笔者的启蒙书，十分全面与系统，方方面面都有介绍，正如书名，从小工到专家，这本书足矣。另外第二版相较于第一版添加了不少内容，版本基于12，建议选购第二版。推荐指数

internal》，笔者正在翻译成中文阿里内核月报系列PostgreSQL源码解读系列...学会利用好轮子，站在前辈肩膀上，都可以大大方便我们查找跟踪代码。另外一个就是积累的过程了，需要对

条件不含排序字段走排序字段索引情况下，有可能通过索引匹配到第一条符合条件的数据会比较久，就是说要考虑索引扫描的整体代价作为

的调整真的是一门很大的学问。我见借着这个案例，也聊聊我对社区的浅薄看法吧，经常有人会纳闷为什么社区这不做，那不做，明明都是问题！就此例中的问题，其实早在

https://www.postgresql.org/docs/current/runtime-config-developer.html只读参数data_checksums

年，对今年的自己有个认知与交代。行远自迩首先还是聊聊自己的吃饭技能——PostgreSQL，当下不管是国产化替代，还是当红炸子鸡——AI，天时地利都十分利好于

case不过计划很丰满，时间只有两个半小时，我会尽可能和各位多分享点干货。下午的话会聊聊时序数据库。目前PostgreSQL优化器内幕剖析

cache和文件系统通常默认是4KB，然后就是存储层，老式HDD扇区通常是512字节，新一点的可能是4KB。SSD的话会更加复杂一点，通常在4KB

前言这个问题是前几天②群一位群友问的问个问题，未提交得事务，WAL也会同步到从节点吗？当时我的回复是："嗯，然后根据commit和rollback，我下来确认一下"。借着这个问题，我又重新思考了一下流复制的原理🤔，又有了一些新的思考，甚好甚好。分析首先这个问题的答案无疑，是肯定会同步到从节点，这一点和逻辑复制有所不同，之前也写过一篇逻辑复制处理大事务的演进，在14版本逻辑复制才正式引入了"流式"传输，即未提交的事务也会流式传输到订阅端，以前都是直到事务提交时才会一股脑发送至订阅端，所以碰到大事务就歇菜。但是，流复制和逻辑复制有所不同，这一点其实很好验证

前言熟悉我的读者应该知道，PostgreSQL学徒是一个专注于分享技术的公众号，一直以来我也坚持在分享PostgreSQL相关技术文章。今天这篇文字应该是我首次写非技术类开喷的文章。起因是某"知名"培训博主，随意搬运我的文章，沟通多次无果，屡教不改，实在没崩住，遂有此文。前因后果其实很早我就关注了此技术公众号：DB宝，看了一下，有240个朋友也在关注，想着也是一名"技术大V"，但是其白嫖成性的行为实在忍无可忍。后面，我通过了公众号发的群链接加入了技术交流群——小麦苗DB宝(6)，各位可以看到，其实早在去年10月30号，我就发现搬运了我的文章——一个主键重复案例，https://www.xmmup.com/yigepgzhujianzhongfudeanlifenxiang.html（现在已删除），各位看到的密码保护的文章都是经过我交涉之后，让他删掉的结果。并且这个截图，有句话很刺眼：哈，原来这是你写的呀！这篇文章是我在10月26号写的，他在10月30号就嫖成了他的"创作"，效率杠杠的👍🏻。原文：主键重复的有趣案例，然后我去看了下他的"创作"，发现居然一字未改，这里暂且不论观看他的"创作"需要关注其公众号DB宝，获取验证码，这本无可厚非，引流嘛培训嘛赚钱嘛。于是我就在群里提醒了一句：记得转载声明，写在最前面。想必这几个字不难理解吧？应该都看得懂吧？要求就两个写明来源放在文章前面这位作者回复到：后边都有链接地址，若不愿意我搬运，我删除即可。行吧，说明这位作者还是有版权意识，尊重他人劳动成功，注明了来源，可是我还是被无情地打脸了。我去看了下他所谓的链接地址，惊呆了！(由于目前估计被投诉交涉太多，目前已经无法直接公众号获取验证码了)这个意思是，要付费给他然后来阅读我的文章？我找了一个历史文章截图，其文章名叫——PG统计信息不正确的一个案例原文是我写的

optimizer，一些常见的优化器刺客，让优化器无所适从。参考https://leovan.me/cn/2019/04/heuristic-algorithms/Master

前言今天是PostgreSQL数据库生态大会的第二天，诸位演讲嘉宾共同带来了一场精彩纷呈的技术盛宴，在会场也碰到了很多老朋友与数据库圈的前辈，收获颇丰。回到文章主题，起因是在③群中，一位筒子提到：“库下面分配了

recommended.AO表适用于数仓中的事实表，数据量不断增长，通常批量加载大批量数据。小结至于为什么在vpinfo中没有查询到0xdb，来自japin的解释是“由于这个结构体的前面是

前言之前写了一篇深入浅出VACUUM内核原理(上)，赶巧最近有位读者和我探讨了一个问题，恰巧也和vacuum的有趣特性有关，借此再增加一篇深入浅出VACUUM内核原理(中)。那么是什么样的特性呢？没错，又是我们的老朋友——页剪枝。现象简单重温下页剪枝，有两种情况会进行剪枝，以删除在任何快照中不再可见的元组之前的

worker的时间间隔不会大于autovacuum_naptime优先对xid或者multixact快要回卷的数据库进行清理越长时间没有经过自动清理的数据库优先被清理另外也会类似于skip

会在同一个逻辑文件中相互交织。每次写入都是原子性的，一条记录一条记录的写。内存里的WAL缓冲区中的内容，会被各种进程写入/刷入持久化磁盘上的WAL文件里。当前写入内存WAL缓冲区的逻辑日志位置点称作

----+------------+--------+-------+-----------------+--------------------------------+----------

等等。至于鸡生蛋还是蛋生鸡，各位读者可以翻阅之前的文章，这里就不再赘述原理。让我们看下第二个问题：手动刷新物化视图，物化视图不包含死元祖，但是生产中却包含死元组。首先，截止最新版本，原生

目录以查找父事务和子事务的可见性关系当同时存在长事务和子事务时，要格外小心，系统的性能很容易骤降，备库的查询会瘫痪OK。以上是此篇分享的上半部分，下半部分留到下篇文章继续分析。4参考PGConf

1前言这几天被一个生产问题折磨得死去活来，CPU愣是给我干烧了，在上周某天晚上，业务反馈业务响应速度骤降，但是DBA上去执行慢SQL却特别快，经过排查，居然是不同的用户，生成的执行计划不一样！DBA表示惊呆了，虽然我很早之前也分享过一篇类似的案例（11的原生分区）

bpf_errstart)除此之外，pg_lock_tracer还支持五种"事件"的追踪👆🏻另外一个提供的工具是pg_lw_lock_trace，顾名思义，用于追踪LWLock的examples:#

案例主要是堆表索引等操作导致的，如下👇🏻之前的案例就表过不提了，感兴趣的老铁自己翻一下聊聊基础备份与FPI从一个案例聊聊FPI的危害那么什么场景会产生这样的记录？简单分析一下。2分析既然是

HEAPTUPLE_RECENTLY_DEAD，意味着保留此元祖，不去进行删除。所以，如果系统中含有很久之前开启而未提交的事务，并且这个事务由于执行过更新，创建了事务

"\242\274\245\1\344>\234\375\265\226\2\0o\r\0\0\0\0\0\0\3\0\0\0\0\0\0\0\244(\4\0"...,

参数。3数据库层自身消耗数据库本身会做一些维护性的操作，比如vacuum/freeze等数据库可能有很多大表的年龄会先后到达2亿，数据库的autovacuum会开始对这些表依次进行vacuum

也会随之往前推进），假如一个库比较大并且很繁忙的话，备份就会耗时挺久，同事这个库就是1.5TB，其实也还好。另外值得注意的是，pg_basebackup

的，给人一个还在正常消费的错觉。让我们一起分析下这个怪异的案例！2分析既然是从前天上午就开始保留WAL，遂翻一下前天的日志这一看就发现了端倪，日志中从凌晨开始就不断地在打印如下日内容"oldest

进程去进行了清理，那么为什么放在脚本里会有这样奇怪的行为而手工操作是正常的呢？老办法当我们不知道代码跑了哪些流程的时候，还是老样子，用笨办法全部一股脑抓下来即可。另外根据过往经验，stats

前言前些天，群里有一位童鞋提到这样一个案例："想请教一个问题，我的环境，我看后台只有一个delete在不停的执行，但是WAL日志涨的却非常快，2秒钟就切一个，这个表一共500多万条数据，这种情况正常么？"，不用说肯定不正常🤔，再加上许久之前同事也曾遇到过UUID导致的WAL写放大，那也赶此机会唠唠这个问题。根据过往经验，不同于WAL堆积无法回收，WAL生成速度暴涨一般是由于要么配置了过小的archive_timeout参数导致定时切换WAL的频率过高，要么就是WAL写放大导致实打实生成WAL速度过快，于是让这位童鞋使用pg_waldump看了一下，果然是FPI比例过高导致的WAL写放大。可以看到，最后的汇总处，FPI的比例竟然占据了

前言这几天一直迷迷糊糊脑袋不清醒，没错我也不幸中招了🐑，周一确诊反复低烧高烧，周二好了一天，嘚瑟不到一天就又开始反复发烧，撑到了第四天，脑袋终于清醒多了，也有时间回过头来看工作上或是群里小伙伴提的一些问题。正文第一个问题是："各位大佬，想问下在手工进行分析之后，为什么这些数据还是

LOCALE的比较规则非常简单，就是挨个比较字符码位。当然还有一种方式就是指定额外的操作符了，不过这会增加额外的维护成本，也意味着原来主键/唯一约束自带的索引无法使用postgres=#

----+--------+--------+--------+------------+-----------------------------------+-----------------

文件是什么这些是关于数据库自身的一些比较典型的问题和原理，需要掌握。另外由于数据库和操作系统息息相关，关于操作系统相关的知识也得多多了解，比如内存回收机制：kswapd/direct

前言今天领导找到我提了这么一个需求：想实现权限的精细化控制，然后将这些角色授予给其他业务部门的DBA，不过仅能实现某些操作，这样就不需要我们全权负责了，对方也能做某类运维操作。权限体系共分为三个层级：第一层，允许查询系统表和业务表第二层：包含部分数据库的管理权限，比如杀会话、在SQL跑慢的时候允许创建索引，扩展表空间，收集统计信息，执行

PLAN─────────────────────────────────────────────────────────────────────────────────────Seq

前言之前在群里有位小伙伴问了这么一个问题："各位专家，PG删除了表但是数据文件任然存在的可能性是什么呀"，乍一听有点违背常识。按理删除了表那么对应的文件也会被删除，然后释放所占存储，不然磁盘快爆了结果删除表又不能释放空间就扯淡了。但是事实真是如此吗？让我们一起来分析一下这个有趣的案例

前言最近在群里经常有小伙伴问到学习PostgreSQL推荐的书籍，赶着这个机会，也顺便和各位同步一下我最近在做的事情。书籍推荐首先是向各位推荐一下书籍，下面是笔者个人的看书经历（以下是笔者个人的看法，不带有任何感情色彩，如有误伤十分抱歉），当然肯定还有其他优秀书籍，由于笔者没有看过，这里就不提。《PostgreSQL小工到专家》：唐成老师著，也是笔者的启蒙书，十分全面与系统，方方面面都有介绍，正如书名，从小工到专家，这本书足矣。另外第二版相较于第一版添加了不少内容，版本基于12，建议选购第二版。推荐指数

前言今天下午某位同事找到我说："有个SQL在数据库中执行1ms就能出结果，但是业务压测发起的SQL就会一直执行，查不出结果，进程也没有锁，CPU占用也很高"。让我们一起分析一下这个有趣的案例

前言前一篇我们分析了PostgreSQL中统计信息的作用以及采集算法，这一篇我们分析一下执行计划是如何生成以及如何阅读评估执行计划。相关概念在此之前，先了解下几个概念，方便我们理解。索引首先是耳熟能详的索引，索引本质上就是一个数据结构，用于高效地检索数据，比如BTREE索引，检索一条记录的复杂度是O(LogN)。但这并不意味着索引越多越好，首先索引需要维护会影响写入性能，其次一些功能性的索引也会限制数据的写入（比如CIC留下的无效唯一索引），另外索引越多，优化器要考虑的也会更多，可能会走到糟糕的执行计划参照此图

介绍repmgr是一款开源的用于集群复制管理和故障转移的工具。它扩展了PostgreSQL内建的hot-standby能力，可以设置热备服务器、流复制监控、故障切换等，由2ndQuadrant开发。兼容矩阵如下：repmgr

统计信息前言在之前和各位分享了一篇《PostgreSQL优化器解析》，主要讲解了优化器是如何高效工作的。对于复杂查询，优化器会基于既有的统计信息，高效选择一条最优的执行路径，然后交由Executor去执行。这一章开始，我会聊一聊执行计划的解析，由于整体篇幅较长，大概2万字，我分为两篇来发。上半篇让我们先唠唠PostgreSQL中的统计信息。篇幅较长，涉及到很多枯燥原理和源码分析。统计信息统计信息，想必各位耳熟能详，我们先了解一下为什么数据库需要统计信息以及统计信息的作用，假如现在有这么一条SQL：select

stage.假如还定义有其他的规则，也会在这一阶段进行处理和转化。Planner当重写完成之后，优化器（planner）便会基于查询树生成一颗能被执行器（executor）高效执行的计划树（plan

最近有一些小伙伴咨询关于培训认证的事，有点云里雾里。在此简单科普一下，目前国内有三家做PostgreSQL认证培训的机构•第一家由中国开源软件联盟PostgreSQL分会

time特别长了，这种场景的话，便可以使用绑定变量了，把执行计划缓存起来，以备后用。但是又会经常遇到另一个问题，在此就表过不提了。org.postgresql.util.PSQLException:

前言这两天一直在纠结一个表膨胀的问题，分析的过程很艰辛，但是收获颇丰，请耐心阅读，相信各位能对vacuum和表膨胀理解得更加透彻。现象在2月19号，线上同事找过来说磁盘一直持续上涨，紧急扩容之后不一会又涨上去了。第一反应是不是WAL不断堆积？后来通过查看pg_stat_activity，发现某张表上vacuum跑了40多个小时，并且由于这个表在持续不断地执行update，表一直在膨胀中。不过奇怪的地方在于这个表据开发和运维反馈说之前一直都是正常的，就从18号开始不正常了，磁盘使用率持续上升。于是，登上去看了一下这台出问题的实例（由于涉及到生产安全，做了脱敏，下文都用test表代替生产表）。首先在操作系统层快速看一下，这个进程运行了2416分钟，大约40多个小时，并且还在跑，通过top

前言今天一位朋友找到我，说无法在某个表空间下面创建分区表，自己在复现的过程中也被折磨的晕头转向，直接进入主题，一起看看这个令人费解的现象。现象看一下报错现象，先创建一个表空间和用户postgres=#

前言PostgreSQL单机版我们都很熟悉了，那么基于PostgreSQL分布式数据库呢，那么多鱼龙混杂的产品，如何挑选一款最契合我们的产品呢？这也是本篇文章的由来。本文不会去阐述分布式相关的知识，诸如CAP、BASE、2pc、3pc、TCC、Raft、Saga、TSO、HLC等这些晦涩难懂的知识。本文仅仅做一个PostgreSQL系分布式数据库的科普。注：以下资料均来源于公开资料，侵删。Citus分为开源版（社区版）和商业版。下面针对开源版。官方文档：https://docs.citusdata.com/en/v10.2/介绍Citus是一款基于PostgreSQL的开源分布式数据库，自动继承了PostgreSQL强大的SQL支持能力和应用生态（不仅仅是客户端协议的兼容还包括服务端扩展和管理工具的完全兼容）。和其他类似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL，PostgreSQL-XC相比，Citus最大的不同在于Citus是一个PostgreSQL扩展而不是一个独立的代码分支。因此，citus可以用很小的代价和更快的速度紧跟PostgreSQL的版本演进，同时又能最大程度的保证数据库的稳定性和兼容性。架构architecture.pngCitus的架构如上图所示，为Share