Re: parallel.c is not marked as test covered - Mailing list pgsql-hackers

Andres Freund <andres@anarazel.de> writes:
> I think it's a good idea to run a force-parallel run on some buildfarm
> members.

Noah's already doing that on at least one of his critters.  But some more
wouldn't hurt.

> But I'm rather convinced that the core tests run by all animals
> need some minimal coverage of parallel queries. Both because otherwise
> it'll be hard to get some coverage of unusual platforms, and because
> it's imo something rather relevant to test during development.

+1.  Experimenting with what we might do, it seems like it's harder to get
the planner to use a parallel plan than you would think.

regression=# explain select count(*) from tenk1;                                           QUERY PLAN
                        
 
--------------------------------------------------------------------------------
-------------------Aggregate  (cost=295.29..295.30 rows=1 width=8)  ->  Index Only Scan using tenk1_thous_tenthous on
tenk1 (cost=0.29..270.29 r
 
ows=10000 width=0)
(2 rows)

regression=# set enable_indexscan TO 0;
SET
regression=# explain select count(*) from tenk1;                          QUERY PLAN                            
-----------------------------------------------------------------Aggregate  (cost=483.00..483.01 rows=1 width=8)  ->
SeqScan on tenk1  (cost=0.00..458.00 rows=10000 width=0)
 
(2 rows)

regression=# set force_parallel_mode TO on;
SET
regression=# explain select count(*) from tenk1;                          QUERY PLAN                            
-----------------------------------------------------------------Aggregate  (cost=483.00..483.01 rows=1 width=8)  ->
SeqScan on tenk1  (cost=0.00..458.00 rows=10000 width=0)
 
(2 rows)

Methinks force_parallel_mode is a bit broken.

Also, once you *do* get it to make a parallel plan:

regression=# create table foo as select generate_series(1,1000000) g;
SELECT 1000000
regression=# analyze foo;
ANALYZE
regression=# explain select count(*) from foo;                                     QUERY PLAN
          
 
--------------------------------------------------------------------------------------Finalize Aggregate
(cost=10633.55..10633.56rows=1 width=8)  ->  Gather  (cost=10633.33..10633.54 rows=2 width=8)        Workers Planned: 2
      ->  Partial Aggregate  (cost=9633.33..9633.34 rows=1 width=8)              ->  Parallel Seq Scan on foo
(cost=0.00..8591.67rows=416667 width=0)
 
(5 rows)

regression=# explain (costs off) select count(*) from foo;                QUERY PLAN                 
--------------------------------------------Finalize Aggregate  ->  Gather        Workers Planned: 2        ->  Partial
Aggregate             ->  Parallel Seq Scan on foo
 
(5 rows)

That's not going to do for a regression-test case because it will break
anytime somebody changes the value of max_parallel_degree.  Maybe we
should suppress the "Workers Planned" field in costs-off display mode?
        regards, tom lane