Re: parallel.c is not marked as test covered

On Mon, May 9, 2016 at 11:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I agree.

>> 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)
>    ->  Seq Scan 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)
>    ->  Seq Scan on tenk1  (cost=0.00..458.00 rows=10000 width=0)
> (2 rows)
>
> Methinks force_parallel_mode is a bit broken.

Hmm, that is strange.  I would have expected that to stuff a Gather on
top of the Aggregate.  I wonder why it's not doing that.

> 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.56 rows=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.67 rows=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?

That seems reasonable to me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company