1. 为什么并行查询像高速公路的车道管理？
当你面对TB级数据分析请求或是每秒上万的交易事务时，PostgreSQL的并行查询就像给高速公路增设车道。但不加区分的车道扩建可能导致OLAP场景下资源闲置，或者在OLTP场景中引发交通堵塞。本文将带你深入两个典型业务场景（OLAP大查询与OLTP高频事务），通过实际配置和代码示例揭秘并行度的黄金平衡点。
2. 并行查询的"交通信号灯"——核心参数
三个核心参数控制着并行查询的"车道容量"：
-- 全局总车道数（默认20）
max_worker_processes = 32
-- 并行专用车道数（默认8）
max_parallel_workers = 16
-- 单次查询最大车道数（默认2）
max_parallel_workers_per_gather = 8
这组参数构成如下约束链：
max_parallel_workers_per_gather ≤ max_parallel_workers ≤ max_worker_processes
3. OLAP场景：数据仓库的"大件运输车"
3.1 场景特征
- 单次执行分钟级复杂分析
- 百亿级表关联与聚合
- 资源允许长时间独占
示例1：全表扫描的"车流疏导"
-- 创建测试表（PostgreSQL 15）
CREATE TABLE sales_records (
id BIGSERIAL PRIMARY KEY,
region_code INT,
sale_amount NUMERIC(12,2),
sale_time TIMESTAMP
) WITH (parallel_workers = 32); -- 显式声明期望并行度
-- 查看实际执行计划
EXPLAIN (ANALYZE, VERBOSE)
SELECT region_code, AVG(sale_amount)
FROM sales_records
WHERE sale_time BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY region_code;
-- 输出示例：
-- Gather Merge (cost=1024035.73..1038790.24 rows=25600 width=40)
-- Workers Planned: 6
-- -> Sort (cost=1023035.73..1023145.83 rows=44040 width=40)
-- Sort Key: region_code
-- -> Parallel Seq Scan on sales_records
此时可调高参数：
SET max_parallel_workers_per_gather = 12; -- 根据CPU核心数调整
SET work_mem = '256MB'; -- 防止排序溢出
3.2 参数优化秘籍
- 设置
parallel_leader_participation = off避免协调进程参与运算 min_parallel_table_scan_size调低至16MB以激活小表并行- 对分区表使用
enable_partitionwise_aggregate提升并行效率
4. OLTP场景：交易中心的"快速通道"
4.1 高并发事务陷阱
-- 模拟转账事务（pgbench扩展）
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
-- 当max_parallel_workers_per_gather=8时
SHOW pg_stat_activity;
-- 可能出现：
-- | 等待事件类型 | 等待事件 | 查询 |
-- |--------------|--------------|-------------------|
-- | Lock | transactionid| UPDATE accounts...|
-- | LWLock | ParallelQuery| SELECT ... |
此时需要调整策略：
ALTER SYSTEM SET max_parallel_workers_per_gather = 2; -- 降低并行度
ALTER SYSTEM SET max_parallel_workers = 4; -- 预留OLTP通道
4.2 混合负载救星：资源队列
-- 创建专属通道（pg_stat_statements扩展）
CREATE RESOURCE QUEUE oltp_queue
WITH (active_statements = 50, priority = 100);
CREATE RESOURCE QUEUE olap_queue
WITH (active_statements = 5, priority = 10);
-- 用户绑定队列
ALTER USER web_app SET resource_queue = oltp_queue;
ALTER USER bi_tool SET resource_queue = olap_queue;
5. 隐蔽的"交通法规"——那些你不得不知的限制
5.1 并行禁忌证
-- 非并行安全函数黑名单
CREATE OR REPLACE FUNCTION non_parallel_func()
RETURNS INT AS $$
BEGIN
PERFORM pg_sleep(1);
RETURN 1;
END;
$$ LANGUAGE plpgsql PARALLEL UNSAFE;
-- 执行计划强制串行化
EXPLAIN SELECT non_parallel_func() FROM large_table;
-- Seq Scan on large_table (cost=0.00..592342.00 rows=10000000 width=4)
5.2 锁机制冲突
-- 在并行查询运行时
CREATE INDEX CONCURRENTLY sales_time_idx ON sales_records(sale_time);
-- 将收到警告：
-- WARNING: canceling parallel query due to concurrent DDL
6. 技术选型的"车辆性能测试"
6.1 OLAP优势矩阵
| 技术路径 | 10亿行聚合耗时 | CPU占用峰值 | 资源隔离性 |
|---|---|---|---|
| 单进程查询 | 182s | 100% | 低 |
| 8并行度 | 34s | 800% | 中 |
| 列存储扩展(cstore) | 28s | 650% | 高 |
6.2 OLTP压力测试
使用pgbench进行混合负载模拟：
# OLTP工作负载
pgbench -c 200 -j 8 -T 600 -S oltp_db
# 混合工作负载下不同配置表现：
| 并行度配置 | TPS | 95%延迟 | 错误率 |
|------------|-------|---------|-------|
| 默认配置 | 2356 | 82ms | 0.3% |
| 调优配置 | 2987 | 34ms | 0.08% |
7. 全局调度员的监控宝典
-- 实时并行监控视图
SELECT pid, query, wait_event_type,
pg_blocking_pids(pid) AS blocked_by
FROM pg_stat_activity
WHERE backend_type = 'parallel worker';
-- 历史性能分析
SELECT queryid, calls,
(total_plan_time + total_exec_time)::int AS total_time,
rows,
parallel_workers AS pw
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;
8. 总结：在矛盾中寻找最优解
- OLAP黄金法则：在vacuum完成后的维护期大胆提升并行度至物理核心数的75%
- OLTP生存法则：将并行度控制在物理核心数的25%以下，优先保障事务通道
- 混合部署方案：使用cgroup划分CPU组，为不同服务预留资源通道
- 未来演进方向：关注PolarDB等云原生方案的分层并行架构设计
评论