Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Mar 5, 2021 at 9:35 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Mar 5, 2021 at 8:24 AM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> >
>
> In patch v21-0003-Add-new-parallel-dml-GUC-and-table-options, we are
> introducing GUC (enable_parallel_dml) and table option
> (parallel_dml_enabled) for this feature. I am a bit worried about
> using *_dml in the names because it is quite possible that for
> parallel updates and parallel deletes we might not need any such GUC.
> The reason we mainly need here is due to checking of parallel-safety
> of partitioned tables and updates/deletes handle partitioned tables
> differently than inserts so those might not be that costly. It is
> possible that they are costly due to a different reason but not sure
> mapping those to one GUC or table option is a good idea. Can we
> consider using *_insert instead? I think GUC having _insert can be
> probably used for a parallel copy (from) as well which I think will
> have a similar overhead.
>

I'll need to think about that one.
I may be wrong, but I would have thought at least updates would have
similar parallel-safety checking requirements to inserts and would
have similar potential cost issues.

For the time being at least, I am posting an updated set of patches,
as I found that the additional parallel-safety checks on DOMAIN check
constraints to be somewhat inefficient and could also be better
integrated into max_parallel_hazard(). I also updated the basic tests
with a test case for this.

Regards,
Greg Nancarrow
Fujitsu Australia