On Tue, Mar 2, 2021 at 12:10 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote: > Here is an updated patch with this fix.
Thanks for updating the patch. I was about to post an updated version myself but you beat me to it. > I added regression tests and adapted the documentation a bit. > > I also added support for lowering the number of parallel workers. +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. -- Amit Langote EDB: http://www.enterprisedb.com
