On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar <dilipbal...@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 ...".
Okay, thanks for the feedback. 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. +1, I think it will be cool to support for insert part here as well as insert part in 'Create Table As Select..' as well. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
