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

On Wed, Sep 9, 2020 at 10:20 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > >
> > > > I still don't agree with this as proposed.
> > > >
> > > > + * For now, we don't allow parallel inserts of any form not even where the
> > > > + * leader can perform the insert. This restriction can be uplifted once
> > > > + * we allow the planner to generate parallel plans for inserts. We can
> > > >
> > > > If I'm understanding this correctly, this logic is completely
> > > > backwards. We don't prohibit inserts here because we know the planner
> > > > can't generate them. We prohibit inserts here because, if the planner
> > > > somehow did generate them, it wouldn't be safe. You're saying that
> > > > it's not allowed because we don't try to do it yet, but actually it's
> > > > not allowed because we want to make sure that we don't accidentally
> > > > try to do it. That's very different.
> > > >
> > >
> > > Right, so how about something like: "To allow parallel inserts, we
> > > need to ensure that they are safe to be performed in workers. We have
> > > the infrastructure to allow parallel inserts in general except for the
> > > case where inserts generate a new commandid (eg. inserts into a table
> > > having a foreign key column)."
>
> Robert, Dilip, do you see any problem if we change the comment on the
> above lines? Feel free to suggest if you have something better in
> mind.
>

Hearing no further comments, I have pushed the changes as discussed above.

--
With Regards,
Amit Kapila.