>Thanks a lot for the tests. In your test case, parallel insertions are not >being picked because the Gather node has > some projections(floor(((random() * '10000'::double precision) + >'1'::double > precision)) to perform. That's expected. >Whenever parallel insertions are chosen for CTAS, we should see "Create >target_table '' under Gather node [1] and >also the actual >row count for Gather node 0 (but in your test it is >rows=100006268) in the explain analyze output. >Coming to your test case, if it's modified to something like [1], where the >Gather >node has no projections, >then parallel insertions will be chosen.
Thanks for your explanation and test. Actually, I deliberately made my test case(with projection) to pick serial insert to make tuples unbalance distribution(99% tuples read by one worker) happened. This issue will lead the performance regression. But it's not introduced by your patch, it’s happening in master(HEAD). Do you have some thoughts about this. >[1] - I did this test on my development system, I will run on some performance >system and post my observations. Thank you, It will be very kind of you to do this. To reproduce above issue, you need to use my case(with projection). Because it won’t occur in “parallel insert”. Regards, Tang
