Re: A reloption for partitioned tables - parallel_workers

On Tue, 2021-03-02 at 11:23 +0900, Amit Langote wrote:
> +ALTER TABLE pagg_tab_ml SET (parallel_workers = 0);
> +EXPLAIN (COSTS OFF)
> +SELECT a FROM pagg_tab_ml WHERE b = 42;
> + QUERY PLAN
> +---------------------------------------------------
> + Append
> + -> Seq Scan on pagg_tab_ml_p1 pagg_tab_ml_1
> + Filter: (b = 42)
> + -> Seq Scan on pagg_tab_ml_p2_s1 pagg_tab_ml_2
> + Filter: (b = 42)
> + -> Seq Scan on pagg_tab_ml_p2_s2 pagg_tab_ml_3
> + Filter: (b = 42)
> +(7 rows)
>
> I got the same result with my implementation, but I am wondering if
> setting parallel_workers=0 on the parent table shouldn't really
> disable a regular (non-parallel-aware) Append running under Gather
> even if it does Parallel Append (parallel-aware)? So in this test
> case, there should have been a Gather atop Append, with individual
> partitions scanned using Parallel Seq Scan where applicable.

I am not sure, but I tend to think that if you specify no
parallel workers, you want no parallel workers.

But I noticed the following:

SET enable_partitionwise_aggregate = on;

EXPLAIN (COSTS OFF)
SELECT count(*) FROM pagg_tab_ml;
QUERY PLAN
------------------------------------------------------------------------------
Finalize Aggregate
-> Gather
Workers Planned: 4
-> Parallel Append
-> Partial Aggregate
-> Parallel Seq Scan on pagg_tab_ml_p1 pagg_tab_ml
-> Partial Aggregate
-> Parallel Seq Scan on pagg_tab_ml_p3_s1 pagg_tab_ml_3
-> Partial Aggregate
-> Parallel Seq Scan on pagg_tab_ml_p2_s1 pagg_tab_ml_1
-> Partial Aggregate
-> Parallel Seq Scan on pagg_tab_ml_p3_s2 pagg_tab_ml_4
-> Partial Aggregate
-> Parallel Seq Scan on pagg_tab_ml_p2_s2 pagg_tab_ml_2
(14 rows)

The default number of parallel workers is taken, because the append is
on an upper relation, not the partitioned table itself.

One would wish that "parallel_workers" somehow percolated up, but I
have no idea how that should work.

Yours,
Laurenz Albe