PostgreSQL14大表SELECT count(*)优化及并行worker未启动问题咨询

语句执行层优化 #

• 非实时精确计数场景，直接用系统统计量估算，毫秒级返回结果：

SELECT reltuples::bigint FROM pg_class 
WHERE relname = 'product' AND relnamespace = 'public'::regnamespace;

误差通常在5%以内，适合大多数不需要100%准确行数的业务场景。

• 必须要精确计数的场景，可新增计数触发器：在product表上创建insert/delete触发器，每次数据变更时同步更新一张独立的计数汇总表，查询时直接读取汇总表数值，性能可提升数个量级，适合写入压力不算极端的业务。
• 你当前执行计划中Heap Fetches高达4600多万，说明表的可见性映射未更新，先执行VACUUM ANALYZE public.product;清理死元组、更新可见性映射，可大幅降低Index Only Scan的额外回表开销，直接提升单查询速度。

数据库配置调整 #

• shared_buffers：设置为总内存的25%，也就是16GB，适配PostgreSQL缓存分配规则。
• effective_cache_size：设置为总内存的75%，也就是48GB，告知优化器有足够的系统缓存可用，更倾向于选择索引扫描方案。
• work_mem：全局可设置为16~32MB，执行count查询时可临时调大到64MB，避免聚合过程中写临时文件。
• maintenance_work_mem：设置为2GB，可大幅提升VACUUM、建索引等维护操作的执行速度。
• 并行相关参数：max_parallel_workers_per_gather设为8~12，max_parallel_workers设为16，适配你20线程的硬件配置；适当调小parallel_setup_cost到100、parallel_tuple_cost到0.1，降低优化器启用并行执行的阈值。

该现象属于异常情况，核心原因是查询执行时没有可用的并行worker资源，常见诱因如下：

1. 并行相关参数配置过小：如果max_parallel_workers全局总并行worker数设置过低，或者max_parallel_workers_per_gather单查询允许的并行worker数小于规划值，都会导致无法启动并行worker。
2. 瞬时资源占用：执行查询时，其他正在运行的任务已经占满了所有可用的并行worker，没有剩余资源分配给当前查询。
   你当前的count查询实际是单线程执行了9000万行索引扫描，这也是执行时间长达330秒的核心原因之一，调整上述并行相关参数后，即可正常启动并行worker，扫描速度可提升3~4倍。

内容的提问来源于stack exchange，提问作者JohnDotOwl