iihero@优快云

在执行大量写操作的系统上，调优检查点对于获得良好的性能至关重要。然而，检查点是我们经常发现混淆和配置问题的地方之一，无论是在社区邮件列表中，还是在为客户提供支持和咨询期间。这篇文章旨在解释检查点是什么——目的和数据库如何实现它——以及如何调优它们。注:这是在2016年最初原作者写的一篇博文的更新版本，更新后反映了PostgreSQL配置的各种变化。否则，总体调优方法基本保持不变。现在您应该了解了检查点的目的，以及调优检查点的基本知识。

下边的内容来自技术博客，感觉内容真心不错。完整的介绍到这里，与大家共享。最近，在调试一个CREATE INDEX操作的性能问题时，我被提醒，PostgreSQL在执行并行查询(包括并行索引创建)时可能会产生临时文件，因为每个工作进程都有自己的内存，可能需要使用磁盘空间来排序或散列表。所以，为了尝试加快索引创建，我认为使用tmpfs将这些临时文件直接移动到内存中是有益的，并想测试这个理论，写这篇博客文章:-)

最近，熊二新来的同事小强比较关注国内的一些赛事信息。这不，近期有两大赛事。这两大赛事，主要还是面向高校学生的。一个是搞网络安全方向的:第二届京麒CTF挑战赛，另一个是搞数据库方向的:2024年全国大学生计算机系统能力大赛 数据库管理系统设计赛。CTF (Capture The Flag)，搞网络安全的大都应该知道这个。想懂的都懂，不懂的百度一下就知道咋回事。

国产数据库的发展势不可挡, 趋势不可违逆。

在数据库的使用过程中，有很多场合是要自行去构造大规模数据，以供测试、性能功能验证使用。PostgreSQL - 大规模随机数据生成方法里介绍了PostgreSQL中生成大规模随机数据的方法。这种方法，生成数据比较快，但是数据大多是对业务场景没有太大意义的数据，或者说对业务不够友好。本文再介绍通过一些第三方库，插入一些相对友好的随机数据。那就是通过Python faker库来生成数据。Faker是一个Python软件包，可为您生成伪造数据。

我曾经在DuckDB与PostgreSQL结合一下，PostgreSQL会如虎添翼一文中简要提过DuckDB与SQLite两者之间的关系。在嵌入式开源数据库里头，SQLite是绝对的OLTP的王者，而DuckDB则是或者将是OLAP的王者。本文就简单聊聊SQLite数据库。SQLite的代码质量非常高，一个重要的保证是它的测试覆盖率几乎100%。这种要求尽乎苛刻。盈利思路也非常明确。以它目前的财务状况，很容易支撑到20年后。但是有很重要的一点是，它的专业服务与支持是它生存的亮点。

在PG中，一个简要的体系结构图可以大致画成下边的样子：Server端基本上分成backend process和若干background process。这些process都是一个名为postmaster进程的子进程。而postmaster则是postgres进程的别名。

如果翻一翻最近一两个月的公众号，到处都在散播着，过了35岁，DBA面临着失业的风险。因为再也不需要那么多的DBA了。而一旦失业，再重新找工作，难度相对于年轻的竞争者，不再有那么大的优势了。事实果真如此吗？如果遇到了，该如何面对？啰啰嗦嗦地说了些个人体会，其实，不当对DBA，对于所有从事IT相关工作的人，或许都有些启发。祝看到本文的广大老铁，与身体和平相处，能顺利应对各类变化，可以有远虑，行动配套上就足矣。微信公众号：数据库杂记 个人微信: _iihero我是iihero. 也可以叫我Sean.

挖一挖：PostgreSQL Java里的double类型存储到varchar精度丢失问题写完之后，有热心的朋友， 就发留言问，那个log配置了半天，好像不太管用。就是说，用了自定义的配置文件，最后都不起作用，看不到有效的输出。首先强调一下，PG数据库的外围生态是非常完善的，就是说，它几乎支持各种主流的访问接口，这个完全为亚于当规模最大使用范围最广的一些大型商用数据库。从这个角度来看，它的发展前景不可限量 ，最贴近它自身的外围用户不就是使用这些访问接口的广大开发人员吗？内容与上边定义的相同。

PostgreSQL数据库，由于其自身特有的MVCC机制，它没有自己的Undo Log。更新操作相当于一个删除叠加一个插入操作，反映在表数据文件当中就是内部的一条新增记录，加上原有记录的删除。那些已被删除的元组(死元组)所占的空间如果得不到及时的回收，那么表数据文件所用空间将会不断膨胀，查询及其它CUD操作也会变慢，直到系统不可承受。这就是AutoVaccum存在的原因。

昨天，一朋友向我咨询Sybase ASE中定长字符串类型的行为，说他们的客户反映，同样的char类型的数据，通过jdbc来查，Sybase库不会带空格，而PostgreSQL会带。而varchar(N) NULL与NOT NULL，行为也一致，无论是直接取值，还是拼接后再取值，都留一个多余的字符(长度够宽的话)。这样来看，只要不在SQL语句里头拼接，那么char(N) NULL或NOT NULL，两种数据库的行为应该是一样的。如果是Not Null的char(N)，则不会截掉空格，无论是否与其它字符拼接。

try {// 连接到数据库)";= null) {发现 PostgreSQL11和12及以后的版本，插入到表t1中的记录值不一样。a48(3 rows)a------4848.148.9(3 rows)这个问题如何分析？从驱动层来看，发送过去的内容或指令应该是一样的。

默认情况下，所有新建的数据库对象都建立在这个表空间下，对应的根目录是$PGDATA/base。而pg_global对应的是全局表空间，对应的根目录是$PGDATA/global。它到底指的是哪个表空间，显而易见，它就是pg_default表空间。我们可以想象，你database, tablespace之类的，甚至还有role之类的定义，肯定要放到全局共享的地方，以保证每个数据库在检索的时候，可以检索得到。官方文档中的定义是，pg_global中存放的都是同一个实例当中全局共享的对象。我们一样也可以得到。

PostgreSQL数据库的MVCC机制中，一个明显的特点是，在执行DELETE操作，它一般并不立即擦除要删的数据，通常只是做一个标记，留给VACUUM进程去做相应的清理，并且是有条件的清理。再补充一个小的验证性测试，如果我们将fillfactor调整为20， 预留80%的空间给update操作，看看第1种情况下，花的时间是啥样的？在实际使用当中，对于高频的更新操作的表，为减轻vacuum的负担，可以建议性的将fillfactor调整为80或75，给Update操作预留适当的空间。这些都是要占有空间的。

针对PostgreSQL进行压缩，有很多相关的工具。有同学又要问了，为何还要再搞一个？比如，pgbench, sysbench之类的，已经很强大了。是的，它们都很强大。但有时候，在一些特殊的场景，可能自己构造一个更能接近真实的生产环境。这里，我半写，半借助于ChatGPT，搞出一个代码片段来模拟启动一段多线程并发SQL请求，作用于PostgreSQL数据库。然后，你可以对请求执行完以后的结果进行观测，尤其是表膨胀，受影响记录条数之类的。基于此，我们还可以进行持续改造，快速用于工作之中。

最近在CF (Cloud Foundry) 云平台上遇到一个比较经典的案例。因为牵扯到JVM （app进程）与数据库连接两大块，稍有不慎，很容易引起不快。在云环境下，有时候相互扯皮的事蛮多。如果是DB的问题，就会找DB相关部门。关键是如何自证。涉及到职场生存法则，大家都不愿意去背锅，谁背锅，意味着谁要担责。下边我们看看这个案例。有的时候，问题不是孤立存在的，从各个层面进行分析，逐个排错，最后还是能找到出问题的原因。如何规避此类事件再次发生，只能进一步加强监控。

这里简要介绍一下PG中的Copy以及\Copy快速加载数据的基本用法及注意事项。同时也比较了Batch Insert与Copy之间的性能差异。它们在PG日常维护与使用的场景中经常要用到。

创建file_fdw 扩展创建外部表(file_fdw)24 empno int, -- primary key, 此处不能加外键7 age int,像普通表一样访问外部表使用元命令 \des 和 \det 查看库中有哪些外部表和外部服务器模块提供了外部数据包装器，它可以被用来访问存储在外部PostgreSQL服务器中的数据。这个模块提供的功能大体上覆盖了较老的dblink模块的功能。但是提供了更透明且更兼容标准的语法来访问远程表，并且可以在很多情况下给出更好的性能。

如若转载，请尊重个人劳动，务必注明原始出处。iihero 2008-9-28于优快云前几天，偶然从论坛里看到帖子，有人问：手头只有oci.dll文件，似乎对应的头文件也有。但是就是找不到对应的lib文件。想让人家邮件发给他一个。我回忆了一下，好像微软的VC开发工具包里头，有命令可以直接生成对应的lib文件，这样，对于开发人员来说，只要有相应版本的dll文件和头文件，无须对应的l...

第一次用Postgre，已经是好多年以前了，隐约记得是在linux下边，build半天，然后手动配置库文件之类。今天在整理资料的时候发现，Postgre出现了解压缩直接使用的版本，上边注明了for expert only. 呵呵，看来，不推荐生手使用。为了试验一把，索性从它的官网上直接下载了一份postgresql-8.3.3-1-binaries-no-installer.zip...

refer to: https://www.postgresql.org/docs/14/datatype.html为避免一些不必要的麻烦，不要用关键字去定义数据库对象的名字。它会给PG的解析造成潜在的问题。尤其是在生产环境中，不要给自己制造麻烦。E前缀，C风格的转义符位串常量，二进制使用B前缀，16进制采用X作前缀3、简单SQL3.1、基础SQL建表删表更改表see: https://www.postgresql.org/docs/14/sq

PostgreSQL中对于稍长一点的列，直接使用了TOAST表来存储，默认是会对表中的数据进行压缩的。关于TOAST, 以后或有时间专门做简单介绍。这是一个很有意思的话题。尤其是在我们做物理设计和空间大小评估的时候。这里以table相关size为例，重点介绍一下。如何计算对应的toast表相关的空间大小？数据库中表的物理大小。

它的路径位于：控制文件里存储了数据库唯一系统标识符、系统状态数据、数据库启动前系统必须恢复到的检查点信息、数据库的配置兼容backend进程执行的参数、指明类型timestamp、interval、time内部格式的标志、指明不同类型传值（pass-by-value）状态的标志以及一些数据库的重要信息。我们可以通过pg_controldata命令直接读取PostgreSQL控制文件内容。控制文件内容主要分为是三部分，初始化静态信息、WAL及检查点的动态信息、一些数据库配置信息。

不多说，已经在github上开源：https://github.com/iihero/benchmarksql-v5。

关于 Odyssey ，它是一种相对高级的多线程 PostgreSQL 连接池。内部采用异步的多线程体系结构，使用事件驱动的异步方式来实现 内部逻辑，但是对外提供的接口看起来仍像是同步的过程方式，而没有采用回调的方式来实现，便于开发人员使用。从支持程度来讲，它的多线程方式比pgbouncer似乎更胜一筹，单个应用能更好的利用CPU，并且可以支持更大规模的并发。最近在总结PG的一些连接池的使用时，体验了一把Odyssey(奥德赛)连接池。顺便说一句，俄国的工程师水平还是相当不错的。

微信公众号：数据库杂记 个人微信: _iihero我是iihero. 也可以叫我Sean.Sean@墨天轮 (https://www.modb.pro/u/16258)数据库领域的资深爱好者一枚。SAP数据库技术专家与架构师，PostgreSQL ACE.水木早期数据库论坛发起人db2@smth. 早期多年水木论坛数据库版版主。国内最早一批DB2 DBA。前后对Sybase, PostgreSQL, HANA,Oracle, DB2, SQLite均有涉猎。

DBA的工作范围以内，比较头疼的几件事之一，恐怕就是数据被误删。于是经常看到网上的一些文字，诸如：”删库跑路“。那也只是戏说，真正追究起来，跑是不跑不掉的。所以，千万不要干傻事。经验老道的DBA，向来是拿”备份“技术作为生存第一要素。数据丢了，连过去的有效备份都不具备的话，那可真是要被迫跑路了。本文试着从另外一个角度，即防御角度，看看PostgreSQL中如何通过事件触发器来阻断用户的drop table或truncate table之类的操作。顺便对PostgreSQL中的事件触发器的使用做些介绍。

PostgreSQL中的CTE:公共表表达式是一种更好的临时表. 用于较大查询的辅助语句.用于只在一个查询中存在的临时表。在WITH子句中的每一个辅助语句可以是一个SELECTINSERTUPDATE或DELETE，并且WITH子句本身也可以被附加到一个主语句，主语句也可以是SELECTINSERTUPDATE或DELETE。这也是PostgreSQL的一个非常重要的功能。有很多商用关系数据库甚至还没有这个特色功能。仔细再读了下这篇文档，感觉组织的不是很理想。试图重新组织一下，便于理解其中的使用方法。

今天晚上终于挤出点时间听了听OSC的现场直播，视频太卡，还好能听到各位大牛的声音。讨论的是DBA这个职业或者工种会不会被“云”的大环境淘汰。既然将这种话题列到直播现场，除了吸引大家的关注以外，本身也意味着不少相关技术人员对于DBA这个工作方向存在带有焦虑。人无远虑，必有近忧。讨论这个问题的前提，没有在讨论前下明确界限，就很容易造成相互的“扯”，你认为这个是DBA工作范围，他认为不是，认为DBA工作内容是别的***。

我们在各种生产环境或者开发测试环境中，一定遇到有很多信息都是使用JSON串或者文本文件作为输入的。在没有JQ命令行工具之前，我们要从中获取真正的输入，大都把它复制到文本里头，然后使用文本编辑器进行加工整理。比如，提取用户名（username)、密码（password)、连接的url、证书(certificate)等。b73"上边的信息已经做过脱敏处理。我们使用jq就可以快速得到相关项的值。上边所有内容只是很基础的一部分使用。

PostgreSQL遵循小版本的发布规律，这一个季度的小版本又发布了。可以算作是2024年第一个季度的版本发布。如果总结其规律：大概就是2月、5月、8月、11月的样子。通常因为11月配合大版本的发布，它是起点，也有可能就是终点。起点可能是*.0，也有可能是*.1。于是你在标题里头，可以看到14.11这样的版本号。（正常情况，应该是14.8)。但是总体来说应该是每个季度一次小版本的发布更新。CVSS v3 Base Score 分数达到8.0分。超过7/7.5分的，一般都属于高等级的安全问题了。

SAP云应用程序编程模型(CAP)是一个语言、库和工具框架，用于构建企业级服务和应用程序。它引导开发人员沿着一条经过验证的最佳实践的“黄金之路”前进，并为反复出现的任务提供大量开箱即用的解决方案。我们这就来看看SAP BTP的CAP到底提供了哪些便利。也以PostgreSQL作为数据库的后端为例 ，看看如何简单的应用CAP相关技术和技术栈。CAP不仅可以快速生成云上的应用，也可以生成本地可以运行的应用。CAP框架的特点是混合了经过验证并被广泛采用的开源和SAP技术，如下图所示。

SQL查询当中，In和Exists子查询到底有无区别？记得很多年以前，确实是有相关的使用戒条的，或者说存在一些使用的惯用法。试图完全抹开两者的区别，就有点过了。两者的主要区别：从目的上讲，IN和EXISTS都是SQL中用于子查询的操作符。IN操作符是用来检查一个值是否在一组值中。例如EXISTS操作符是用来检查一个子查询是否至少返回一个记录。1. 语义上的区别：IN关键字用来查询在某个列表中的数据，EXISTS关键字用来查询是否存在子查询返回的数据。

以前从没有试过建一张表，不带任何列。在PG中却支持这种语法。这是个什么鬼?最近，把PG源码扒了下，简单浏览了下最近的一些merge。简单的说，是它考虑到一张表，在初始SYNC时，有可能没有任何列。按自己的印象，别的DBMS好像没有支持这种语法的。

PostgreSQL的多进程结构，使得在支持大规模连接的时候，服务器端显得比较吃亏。一般上了1000个连接以上的时候，系统就会受到很大影响。这个时候，使用连接池，优势就会突显出来了。在云环境下，一个JAVA应用服务，可能会启动成多个进程实例，而每个进程实例又依赖于java的数据库连接池，不管是Ｈikari，还是阿里的druid，还是其他的一些所谓的高性能连接池，因为都是基于连接会话的，最终并不能对总的连接进程数有多大缓解。在唐成老师的ZQPool 1.3 发布一文中，甚至对此都有吐糟。

前边若干文章，只是简单的介绍了一下PG的手动安装和启动。如：http://blog.youkuaiyun.com/iihero/article/details/8254115 (安装FAQ)循序渐进PostgreSQL: 实现PostgreSQL自启动 循序渐进PostgreSQL: 学习pqxx C++ API访问 使用C编写的动态链接库为PostgreSQL数据库添加自定义函数

本文为iihero原创，如若转载，请注明出处。谢谢。 为简化问题：设表：t(id int, col2 varchar(32)) 1. ASE: 选出重复的行：select * from t group by id, col2 having count(*)>1删掉重复的行，alter table t add col3 int identity not null;delete from t wher

Comparison of different SQL implementationsThe goal of this page — which is a work in progress — is to gather information relevant for people who are porting SQL from one product to another and/or are

这里只是做一个简单的实验，似乎不能完全证明position()函数比like查询要快。SELECT generate_series(1,10) as id, substr('abcdefghijklmnopqrstuvwxyz',1, (random()*26)::integer) as col2 into t1;

如若转载，请务必注明出处。iihero 2008.9.26于优快云 本来想写写MS SQL Server的发展历史。但想想，基本上在谈Sybase ASE的时候，也把它都谈到了。MS SQL Server发展到现在，确实是非常的成功。 它的传播面很广，总结起来，有几点： 1. 似乎盗版传播很容易，一个序列号破解，就可以无限期使用。对于Sybase ASE，简直是不可能的事。它的license策略