On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar <dilipbalaut@gmail.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
