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

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Date: 2020-09-25 11:41:06
Message-ID: CAJcOf-fBhLuuO-cxNDCokd=JtdbzOadr9iQtwnvxKa-WX71wBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 25, 2020 at 7:01 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> I have few points (inspired from parallel copy feature work) to mention:
>
> 1. What if the target table is a foreign table or partitioned table?
> 2. What happens if the target table has triggers(before statement,
> after statement, before row, after row) that are parallel unsafe?
> 3. Will each worker be doing single row insertions or multi inserts?
> If single row insertions, will the buffer lock contentions be more?
> 5. How does it behave with toast columns values?
> 6. How does it behave if we have a RETURNING clause with INSERT INTO SELECT?
>

Hi Bharath,

Thanks for pointing out more cases I need to exclude and things I need
to investigate further.
I have taken note of them, and will do more testing and improvement.
At least RETURNING clause with INSERT INTO SELECT is working!

Regards,
Greg Nancarrow
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message legrand legrand 2020-09-25 11:57:37 Re: enable pg_stat_statements to track rows processed by REFRESH MATERIALIZED VIEW
Previous Message Asif Rehman 2020-09-25 11:39:46 Re: BUG #16419: wrong parsing BC year in to_date() function