On Fri, Oct 16, 2020 at 9:26 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > Cool, let me try to explain my thoughts a bit more. The idea is first > (in standard_planner) we check if there is any 'parallel_unsafe' > function/expression (via max_parallel_hazard) in the query tree. If we > don't find anything 'parallel_unsafe' then we mark parallelModeOk. At > this stage, the patch is checking whether there is any > 'parallel_unsafe' or 'parallel_restricted' expression/function in the > target relation and if there is none then we mark parallelModeOK as > true. So, if there is anything 'parallel_restricted' then we will mark > parallelModeOK as false which doesn't seem right to me. > > Then later in the planner during set_rel_consider_parallel, we > determine if a particular relation can be scanned from within a > worker, then we consider that relation for parallelism. Here, we > determine if certain things are parallel-restricted then we don't > consider this for parallelism. Then we create partial paths for the > relations that are considered for parallelism. I think we don't need > to change anything for the current patch in these later stages because > we anyway are not considering Insert to be pushed into workers. > However, in the second patch where we are thinking to push Inserts in > workers, we might need to do something to filter parallel-restricted > cases during this stage of the planner. >
Posting an updated Parallel INSERT patch which (mostly) addresses previously-identified issues and suggestions. More work needs to be done in order to support parallel UPDATE and DELETE (even after application of Thomas Munro's combo-cid parallel-support patch), but it is getting closer. Regards, Greg Nancarrow Fujitsu Australia
v5-0001-Enable-parallel-INSERT-and-or-SELECT-for-INSERT-INTO.patch
Description: Binary data