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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Greg Nancarrow <gregn4422(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Date: 2020-09-26 05:29:44
Message-ID: CAA4eK1KvtXKG3esA_H=363_fU-Kp7pAwbY3vnuSNAameeO3JjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 25, 2020 at 2:31 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> On Tue, Sep 22, 2020 at 10:26 AM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> >
> > For cases where it can't be allowed (e.g. INSERT into a table with
> > foreign keys, or INSERT INTO ... SELECT ... ON CONFLICT ... DO UPDATE
> > ...") it at least allows parallelism of the SELECT part.
> >
>
> Thanks Greg for the patch.
>
> 2. What happens if the target table has triggers(before statement,
> after statement, before row, after row) that are parallel unsafe?
>

In such a case, the parallel insert shouldn't be selected. However, we
should still be able to execute the Select part in parallel.

> 3. Will each worker be doing single row insertions or multi inserts?
> If single row insertions, will the buffer lock contentions be more?
>

I don't think the purpose of this patch is to change the basic flow of
how Insert works and also I am not sure if it is worth the effort as
well. I have answered this earlier in a bit more detailed way [1].

[1] - https://www.postgresql.org/message-id/CAA4eK1Ks8Sqs29VHPS6koNj5E9YQdkGCzgGsSrQMeUbQfe28yg%40mail.gmail.com

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-09-26 05:30:04 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message Amit Kapila 2020-09-26 05:16:51 Re: Parallel INSERT (INTO ... SELECT ...)