本文探讨了PostgreSQL分区表在数量过多时，执行计划耗时导致的性能问题，特别是对OLTP系统的影响。通过分析，发现大量BIND、SPIN LOCK和SLEEP进程占用CPU资源。解决方案包括调整分区粒度、利用edb_enable_pruning参数和pg_pathman分区功能来优化执行计划。
摘要： 标签 PostgreSQL , 分区表 , bind , spin lock , 性能分析 , sleep 进程 , CPU空转 , cache 背景 实际上我写过很多文档，关于分区表的优化： 《PostgreSQL 商用版本EPAS(阿里云ppas) - 分区表性能优化 (堪比pg_pathman)》 《PostgreSQL 传统 hash 分区方法和性能》 《PostgreSQL 10 内置分区 vs pg_pathman perf profiling》 实际上native分区表的性能问题主要还是在于分区表过多的时候，执行计划需要耗时很久。
点此查看原文：https://yq.aliyun.com/articles/405176?spm=a2c4e.11153959.teamhomeleft.44.8WKxt7
实际上native分区表的性能问题主要还是在于分区表过多的时候，执行计划需要耗时很久。
因此有了
1、PPAS的edb_enable_pruning参数，可以在生成执行计划前，使用简单SQL的话，直接过滤到目标分区，从而不需要的分区不需要进入执行计划的环节。
2、pg_pathman则支持的更全面，除了简单SQL，复杂的表达式，immutable都可以进行过滤，过滤到目标分区，从而不需要的分区不需要进入执行计划的环节。
因分区表过多引发的问题通常出现在OLTP系统（主要是OLTP系统的并发高，更容易把这种小问题放大），本来一次请求只需要1毫秒的，但是执行计划可能需要上百毫秒，也就是说执行耗时变成了小头，而执行计划（SPIN LOCK）变成了大头。
下面这个例子也是OLTP系统相关的，有具体的原因分析。
SQL访问的分区表过多，并发高时CPU负载高，但是大量的是SLEEP状态的BIND进程。
某个业务系统，单次SQL请求很快，几十毫秒，但是并发一高，QPS并没有线性的增长。
而且大量的进程处于BIND，SLEEP的状态。
经过诊断，
《PostgreSQL 源码性能诊断(perf profiling)指南》
主要的原因是大量的SPIN LOCK，导致CPU空转。
perf record -ag
perf report -g
比如某个进程BIND时的pstack
#pstack 18423
#0 0x00002ad051f3ef67 in semop () from /lib64/lib
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
