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
