PostgreSQL 新版本就一定好--由培训现象让我做的实验
liuaustin3约 13 分钟❝开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3000人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群350+ 9群 100+)
PostgreSQL的版本推进的很快，目前已经到了PG18的非正式版本研发的状态。基于一些数据库产品在推进时容易出现的一些问题，比如新版本的性能在某些方面还不如老的版本这个问题。
我们将展开一个新的PostgreSQL的系列，从相近的版本去发现版本是否存在差异，来从版本的差异上去寻找一些问题。
找差异的方法有很多，我们就从最直接的方式来，我们准备了，两台同样的虚拟机，同样的配置，且虚拟机在同一台物理机上。同样去安装 POSTGRESQL 16.8 和 POSTGRESQL 17.4,用同样的方式去编译数据库，同样的参数。同样的压测的方法。我们来进行数据的采集，最终我们获得版本的差异为我们带来的不同。
一、数据的插入的性能差异。
数据的输入时的性能差异是很多数据库系统在一直优化，且努力让数据写入的速率的，这里我们通过基本pg_bench 来进行简易的测试，在同样配置的数据库中，插入1000万数据，我们来看差距是否存在。我们同样的事情至少做三遍并且我们会将数据列出来。
Initialization started at: 2025-06-02 06:47:53
[postgres@postgresql16 ~]$ pgbench -i -s 100 -U postgres -d my_pgbench_db
dropping old tables...
creating tables...
generating data (client-side)...
2025-06-02 06:48:00.362 CST [10778] LOG: checkpoint starting: wal.89 s)
10000000 of 10000000 tuples (100%) done (elapsed 7.08 s, remaining 0.00 s)
vacuuming...
creating primary keys...
donein 10.31 s (drop tables 0.06 s, create tables 0.06 s, client-side generate 7.32 s, vacuum 0.17 s, primary keys 2.71 s).
[postgres@postgresql16 ~]$ echo"Initialization finished at: $(date '+%Y-%m-%d %H:%M:%S')"
Initialization finished at: 2025-06-02 06:48:03
[postgres@postgresql16 ~]$ echo"end"
[postgres@postgresql17 ~]$ echo"Initialization started at: $(date '+%Y-%m-%d %H:%M:%S')"
Initialization started at: 2025-06-01 10:47:16
[postgres@postgresql17 ~]$ pgbench -i -s 100 -U postgres -d my_pgbench_db
dropping old tables...
creating tables...
generating data (client-side)...
vacuuming...
creating primary keys...
donein 6.86 s (drop tables 0.05 s, create tables 0.00 s, client-side generate 4.96 s, vacuum 0.16 s, primary keys 1.69 s).
[postgres@postgresql17 ~]$ echo"Initialization finished at: $(date '+%Y-%m-%d %H:%M:%S')"
Initialization finished at: 2025-06-01 10:47:23
[postgres@postgresql17 ~]$ echo"end"
除此以外我们还进行了普通的测试，其中包含了客户端从10到50的逐渐数据的查询和DML的操作，下面我们将给出相关的测试脚本和过程。
[postgres@postgresql17 ~]$ bash test.sh
测试结果将保存到: pgbench_results_20250601_120531
---------------------------------------------------------
## 正在运行客户端数量为: 10 的测试 ##
开始时间: 2025-06-01 12:05:31
---------------------------------------------------------
## pgbench 命令执行失败，客户端数量为: 10 ##
请检查错误信息，日志文件: pgbench_results_20250601_120531/pgbench_c10_t30.log
暂停 5 秒，然后继续下一个客户端数量...
## 正在运行客户端数量为: 20 的测试 ##
开始时间: 2025-06-01 12:05:36
---------------------------------------------------------
## pgbench 命令执行失败，客户端数量为: 20 ##
请检查错误信息，日志文件: pgbench_results_20250601_120531/pgbench_c20_t30.log
暂停 5 秒，然后继续下一个客户端数量...
## 正在运行客户端数量为: 30 的测试 ##
开始时间: 2025-06-01 12:05:41
---------------------------------------------------------
## pgbench 命令执行失败，客户端数量为: 30 ##
请检查错误信息，日志文件: pgbench_results_20250601_120531/pgbench_c30_t30.log
暂停 5 秒，然后继续下一个客户端数量...
## 正在运行客户端数量为: 40 的测试 ##
开始时间: 2025-06-01 12:05:46
---------------------------------------------------------
## pgbench 命令执行失败，客户端数量为: 40 ##
请检查错误信息，日志文件: pgbench_results_20250601_120531/pgbench_c40_t30.log
暂停 5 秒，然后继续下一个客户端数量...
## 正在运行客户端数量为: 50 的测试 ##
开始时间: 2025-06-01 12:05:51
---------------------------------------------------------
## pgbench 命令执行失败，客户端数量为: 50 ##
请检查错误信息，日志文件: pgbench_results_20250601_120531/pgbench_c50_t30.log
所有测试阶段完成！
所有详细结果文件位于: pgbench_results_20250601_120531
#!/bin/bash
# --- 配置参数 ---
DB_USER="postgres"# 数据库用户
DB_NAME="my_pgbench_db"# 数据库名
PGBENCH_SCRIPT="custom_mixed.sql"# pgbench 脚本文件
SCALE_FACTOR=100 # 数据缩放因子 (与初始化时保持一致，确保脚本变量正确)
THREADS=8 # 每个pgbench实例使用的线程数 (通常设置为CPU核心数)
DURATION=30 # 每个测试阶段的运行时间 (秒)
PROGRESS_REPORT=5 # 每隔多少秒打印一次进度报告
START_CLIENTS=10 # 起始客户端数量
END_CLIENTS=50 # 结束客户端数量
CLIENT_STEP=10 # 每次增加的客户端步长
PAUSE_SECONDS=5 # 每个测试阶段之间暂停的秒数
OUTPUT_DIR="pgbench_results_$(date +%Y%m%d_%H%M%S)"# 结果输出目录
# --- 函数：打印分隔线 ---
print_separator() {
echo"---------------------------------------------------------"
}
# --- 创建结果输出目录 ---
mkdir -p "$OUTPUT_DIR"
echo"测试结果将保存到: $OUTPUT_DIR"
print_separator
# --- 循环执行 pgbench ---
for clients in $(seq $START_CLIENTS$CLIENT_STEP$END_CLIENTS)
do
echo"## 正在运行客户端数量为: $clients 的测试 ##"
echo"开始时间: $(date '+%Y-%m-%d %H:%M:%S')"
print_separator
OUTPUT_FILE="${OUTPUT_DIR}/pgbench_c${clients}_t${DURATION}.log"
pgbench -f "$PGBENCH_SCRIPT" \
-c "$clients" \
-j "$THREADS" \
-T "$DURATION" \
-r \
-P "$PROGRESS_REPORT" \
-U "$DB_USER" \
-d "$DB_NAME" \
-s "$SCALE_FACTOR" \
> "$OUTPUT_FILE" 2>&1 # 将所有输出重定向到文件
EXIT_CODE=$?
if [ $EXIT_CODE -ne 0 ]; then
echo"## pgbench 命令执行失败，客户端数量为: $clients ##" | tee -a "$OUTPUT_FILE"
echo"请检查错误信息，日志文件: $OUTPUT_FILE"
else
echo"## 客户端数量为: $clients 的测试完成 ##"
echo"结束时间: $(date '+%Y-%m-%d %H:%M:%S')"
echo"结果已保存到: $OUTPUT_FILE"
print_separator
# 打印关键摘要到控制台
echo"摘要 (客户端: $clients):"
grep "tps =""$OUTPUT_FILE" | head -n 1
grep "latency average =""$OUTPUT_FILE"
print_separator
fi
if [ "$clients" -lt "$END_CLIENTS" ]; then
echo"暂停 ${PAUSE_SECONDS} 秒，然后继续下一个客户端数量..."
sleep "$PAUSE_SECONDS"
fi
done
echo"所有测试阶段完成！"
echo"所有详细结果文件位于: $OUTPUT_DIR"
-- custom_mixed.sql
`
-- 联合查询和写入的 pgbench 脚本
-- 随机选择一个账户ID，范围是 1 到 (scale_factor * 100000)
-- 假设 scale_factor = 10，则 aid 范围是 1 到 10000000
\set scale_factor 100
\set aid random(1, :scale_factor * 100000)
\set bid random(1, :scale_factor * 1)
\set tid random(1, :scale_factor * 10)
\set delta random(-5000, 5000)
-- 随机的金额变动 (注释移动到单独一行，或者删除)
BEGIN;
-- 查询操作 1: 查询特定账户的余额
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
-- 写入操作 1: 更新账户余额
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
-- 写入操作 2: 更新出纳员余额
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
-- 写入操作 3: 更新分支余额
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
-- 写入操作 4: 插入历史记录
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, now());
-- 查询操作 2: 联合查询一些数据（例如，从账户表和出纳员表联合查询）
SELECT a.aid, a.abalance, t.tbalance
FROM pgbench_accounts a, pgbench_tellers t
WHERE a.aid = :aid AND t.tid = :tid;
COMMIT;
从数据上看，PG17 PG16 各有自己的特点，但PG16的数据出奇的比PG17的好，我在测试的时候认为是突发情况，就对PG16的数据库又进行了4次测试，对PG17进行了同样的3次此时，最终我不得不把上面的数据呈现出来。
这也是我一直担心的一个问题，新版本的性能比老版本的性能低。出现这个问题在数据库业界并不是少数派事件，在某开源数据库的共识是新的版本的性能逐渐下降对比之前5.7的性能8.0的性能在一些简单的操作上更慢了。
所以这次我也对PG进行了测试没想到得出的结果也让我...... ，同时我也想提醒一件事，也是最近一个培训课上一些同学经常问我的问题，为什么不讲最新的版本。
我的解释是
1 培训大纲的要求
2 新版本未必比旧版本在实用性上强
3 一些同学盲目求新，新版本和旧版本的一些知识体系又了改变，则课上不会在讲之前的一些坑，因为新版本上解决了老版本的问题，这点尤其在PG上非常突出。教学的任务可能对我来说更轻松了，但如果你去的单位用的是老版本，那么你不进行体系化的对老版本的熟悉，你讲无法处理新版本已经不出现，老版本依然是问题的问题。
这也是我这篇文章想说的，数据库相对运维来说更严谨，新版本固然好，但是完全好吗，自己思索思索。
置顶
删除数据“八扇屏” 之 锦门英豪 --我去-BigData！
写了3750万字的我，在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）
跟我学OceanBase4.0 --阅读白皮书 （0.5-4.0的架构与之前架构特点）
跟我学OceanBase4.0 --阅读白皮书 （旧的概念害死人呀，更新知识和理念）
MongoDB 相关文章
MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾
MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项
MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"
MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升
MongoDB 大俗大雅，上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通
MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密（谁是绵羊，谁是怪兽）
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤，来自杭州的Package（活动结束了）
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 （翻译）
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
全世界都在“搞” PostgreSQL ，从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建？” --- 你还真不会！
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然，不是PG的锅
MySQL相关文章