Hi hackers,
I wonder why while calculating cost of parallel scan we divide by parallel_divisor only CPU run cost,
but not storage access cost? So we do not take in account that reading pages is also performed in parallel.
Actually I observed strange behavior when increasing work_mem disables parallel plan even with parallel-friendly tuning:
set parallel_tuple_cost = 0;
set parallel_setup_cost = 0;
set max_parallel_workers = 16;
set max_parallel_workers_per_gather = 16;
set min_parallel_table_scan_size = '16kB';
postgres=# set work_mem = '32MB';
SET
postgres=# explain select sum(payload) from sp where p <@ '((0.2,0.2),(0.3,0.3))'::box; QUERY PLAN
--------------------------------------------------------------------------------------------------- Finalize Aggregate (cost=3427210.71..3427210.72 rows=1 width=8) -> Gather (cost=3427210.67..3427210.68 rows=12 width=8) Workers Planned: 12 -> Partial Aggregate (cost=3427210.67..3427210.68 rows=1 width=8) -> Parallel Bitmap Heap Scan on sp (cost=31994.55..3427002.34 rows=83333 width=4) Recheck Cond: (p <@ '(0.3,0.3),(0.2,0.2)'::box) -> Bitmap Index Scan on sp_p_idx (cost=0.00..31744.55 rows=1000000 width=0) Index Cond: (p <@ '(0.3,0.3),(0.2,0.2)'::box)
(8 rows)
postgres=# set work_mem = '64MB';
SET
postgres=# explain select sum(payload) from sp where p <@ '((0.2,0.2),(0.3,0.3))'::box; QUERY PLAN
--------------------------------------------------------------------------------------- Aggregate (cost=2694543.52..2694543.53 rows=1 width=8) -> Bitmap Heap Scan on sp (cost=31994.55..2692043.52 rows=1000000 width=4) Recheck Cond: (p <@ '(0.3,0.3),(0.2,0.2)'::box) -> Bitmap Index Scan on sp_p_idx (cost=0.00..31744.55 rows=1000000 width=0) Index Cond: (p <@ '(0.3,0.3),(0.2,0.2)'::box)
(5 rows)
In theory, with zero parallel setup cost we should always prefer parallel plan with maximal possible number of workers.
But right now it is not true.
