Re: INSERT INTO SELECT, Why Parallelism is not selected?

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT INTO SELECT, Why Parallelism is not selected?
Date: 2020-07-13 10:53:12
Message-ID: CAA4eK1KAdmwq0t2NH9gvkKrjJZFYw1LXnccKfQo8AwuCEy6Hkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> I have just notice that the parallelism is off even for the select
> part of the query mentioned in the $subject. I see the only reason it
> is not getting parallel because we block the parallelism if the query
> type is not SELECT. I don't see any reason for not selecting the
> parallelism for this query. I have quickly hacked the code to enable
> the parallelism for this query. I can see there is a significant
> improvement if we can enable the parallelism in this case. For an
> experiment, I have just relaxed a couple of checks, maybe if we think
> that it's good to enable the parallelism for this case we can try to
> put better checks which are specific for this quey.
>

+1. I also don't see any problem with this idea considering we will
find a better way to enable the parallelism for this case because we
can already use parallelism for statements like "create table
<tbl_name> as select ...". I think we can do more than this by
parallelizing the Insert part of this query as well as we have lifted
group locking restrictions related to RelationExtension and Page lock
in PG13. It would be really cool to do that unless we see any
fundamental problems with it.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-07-13 11:02:32 Re: proposal: possibility to read dumped table's name from file
Previous Message Dilip Kumar 2020-07-13 10:38:49 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions