如何解决为什么在运行没有“解释分析”的实际查询时，“解释分析”此查询很快完成显示并行计划？
以下查询让我很困惑：
asyncAfter当我运行包含“解释分析”的程序时，它会在
explain analyze
(with z as (
select 1 as attraction,1 as nd_attraction,n.fc
from (select pe_id,zo_id,co_id,value_num as dt
from rtpezocoav x --use view??
where pe_id = 405 and ad_id = 4
) dt
join calc_nodes n on n.co_id = dt.co_id and n.pe_id = 405 and n.se_id = 12
join calc_zones z on dt.zo_id = z.zo_id and z.pe_id = 405 and z.se_id = 12
left join calc_shopconcepts sh on sh.pe_id = 405 and sh.se_id = 12 and sh.sh_id = n.shop_concept and sh.ct_id = n.ct_id
left join rtsepezobrav com on com.se_id = 12 and com.pe_id = 405 and com.zo_id = z.zo_id and com.br_id = n.br_id and com.ad_id = 308 --MV: switched to table instead of view
join rtseperereav rere on rere.se_id = 12 and rere.pe_id = 405 and rere.re_id = z.re_id and rere.re2_id = n.re_id and rere.ad_id = 306 --MV: switched to table instead of view
)
select sum(attraction::float),sum(nd_attraction::float) from z)
我还看到有7个核心短暂启动。但是，当我运行不带解释分析的查询时，它花了2.5秒钟，并且只使用了一个内核。
Finalize Aggregate (cost=455832.88..455832.89 rows=1 width=16) (actual time=397.581..397.581 rows=1 loops=1)
-> Gather (cost=455832.83..455832.84 rows=8 width=8) (actual time=397.355..399.729 rows=8 loops=1)
Workers Planned: 8
Workers Launched: 7
-> Partial Aggregate (cost=455832.83..455832.84 rows=1 width=8) (actual time=382.349..382.349 rows=1 loops=8)
-> Hash Join (cost=9839.72..454742.30 rows=436213 width=0) (actual time=21.295..355.953 rows=627375 loops=8)
Hash Cond: ((z.re_id = rere.re_id) AND (n.re_id = rere.re2_id))
-> Parallel Hash Join (cost=9835.10..451732.66 rows=436213 width=8) (actual time=21.079..286.712 rows=627375 loops=8)
Hash Cond: (x.zo_id = z.zo_id)
-> Parallel Hash Join (cost=4170.35..431738.52 rows=435194 width=12) (actual time=18.544..193.865 rows=627375 loops=8)
Hash Cond: (x.co_id = n.co_id)
-> Parallel Bitmap Heap Scan on rtpezocoav x (cost=1291.48..414863.71 rows=609897 width=8) (actual time=16.846..106.176 rows=627375 loops=8)
Recheck Cond: (pe_id = 405)
Rows Removed by Index Recheck: 104866
Filter: (ad_id = 4)
Heap Blocks: lossy=5558
-> Bitmap Index Scan on rtpezocoav_pe_id_idx (cost=0.00..71.69 rows=5315319 width=0) (actual time=3.754..3.754 rows=578560 loops=1)
Index Cond: (pe_id = 405)
-> Parallel Hash (cost=2843.07..2843.07 rows=2864 width=12) (actual time=1.624..1.624 rows=616 loops=8)
Buckets: 8192 Batches: 1 Memory Usage: 416kB
-> Hash Left Join (cost=126.56..2843.07 rows=2864 width=12) (actual time=0.572..1.348 rows=703 loops=7)
Hash Cond: ((n.shop_concept = (sh.sh_id)::double precision) AND (n.ct_id = sh.ct_id))
-> Parallel Bitmap Heap Scan on calc_nodes n (cost=122.19..2813.20 rows=2864 width=24) (actual time=0.439..0.789 rows=703 loops=7)
Recheck Cond: ((pe_id = 405) AND (se_id = 12))
Heap Blocks: exact=53
-> Bitmap Index Scan on idx_calc_nodes_sepe (cost=0.00..120.97 rows=4868 width=0) (actual time=0.580..0.580 rows=4924 loops=1)
Index Cond: ((pe_id = 405) AND (se_id = 12))
-> Hash (cost=4.33..4.33 rows=3 width=8) (actual time=0.057..0.057 rows=3 loops=7)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Index Only Scan using idx_calc_shopconcepts_sepebr on calc_shopconcepts sh (cost=0.27..4.33 rows=3 width=8) (actual time=0.042..0.043 rows=3 loops=7)
Index Cond: ((pe_id = 405) AND (se_id = 12))
Heap Fetches: 0
-> Parallel Hash (cost=5551.19..5551.19 rows=9085 width=8) (actual time=2.405..2.405 rows=2721 loops=8)
Buckets: 32768 Batches: 1 Memory Usage: 1184kB
-> Parallel Bitmap Heap Scan on calc_zones z (cost=539.91..5551.19 rows=9085 width=8) (actual time=0.657..2.484 rows=5442 loops=4)
Recheck Cond: ((pe_id = 405) AND (se_id = 12))
Heap Blocks: exact=407
-> Bitmap Index Scan on idx_calc_zones_sepe (cost=0.00..534.46 rows=21804 width=0) (actual time=2.351..2.351 rows=21768 loops=1)
Index Cond: ((pe_id = 405) AND (se_id = 12))
-> Hash (cost=4.48..4.48 rows=9 width=8) (actual time=0.080..0.080 rows=9 loops=8)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Index Only Scan using rtseperereav_unique on rtseperereav rere (cost=0.28..4.48 rows=9 width=8) (actual time=0.057..0.060 rows=9 loops=8)
Index Cond: ((se_id = 12) AND (pe_id = 405) AND (ad_id = 306))
Heap Fetches: 0
Planning Time: 3.801 ms
Execution Time: 399.879 ms
是什么原因造成的？
以下是我的设置。我基本上做了以下事情：
Workers Planned: 8; Workers Launched: 0
这些是我的设置：
set max_parallel_workers_per_gather = 8;
set parallel_setup_cost = 0;--1000
set parallel_tuple_cost = 0;
ALTER TABLE rtpezocoav SET (parallel_workers = 8);
该数据库位于Linux（centos-release-7-7.1908.0.el7.centos.x86_64）上。
解决方法
计划8名工人时，有0种工人被解雇有两种可能的解释：
-
所有可用的并行工作程序（
max_parallel_workers）正在使用。考虑到即使您显示了快速计划，这也是可能的解释。在8个计划中的工人中，只有7个可以被启动。 -
您遇到了the documentation中所示的障碍之一。
因此，使用JDBC驱动程序的DBeaver是这里的问题。从现在开始，我将评估psql的性能。谢谢@adrianklaver。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
