On Wed, Sep 9, 2020 at 10:20 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila <amit.kapil...@gmail.com> > > wrote: > > > > > > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas <robertmh...@gmail.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.