Re: parallel.c is not marked as test covered

On Mon, May 9, 2016 at 11:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)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