On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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 ...".
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
