Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Mar 5, 2021 at 12:46 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Mar 5, 2021 at 5:07 AM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> >
> > On Thu, Mar 4, 2021 at 11:05 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Mar 4, 2021 at 5:24 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> > > >
> > > > On Thu, Mar 4, 2021 at 10:07 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > >
> > > >
> > > > >Also, in
> > > > > standard_planner, we should add these partitionOids only for
> > > > > parallel-mode.
> > > > >
> > > >
> > > > It is doing that in v20 patch (what makes you think it isn't?).
> > > >
> > >
> > > The below code snippet:
> > > + /* For AcquireExecutorLocks(). */
> > > + if (IsModifySupportedInParallelMode(parse->commandType))
> > > + result->partitionOids = glob->partitionOids;
> > >
> > > I understand that you have a check for the parallel mode in
> > > AcquireExecutorLocks but why can't we have it before adding that to
> > > planned statement
> > >
> >
> > OK, I think I'm on the same wavelength now (sorry, I didn't realise
> > you're talking about PlannedStmt).
> >
> > What I believe you're suggesting is in the planner where
> > partitionOids are "added" to the returned PlannedStmt, they should
> > only be added if glob->parallelModeNeeded is true:.
> >
> > i.e.
> >
> > /* For AcquireExecutorLocks(). */
> > if (glob->partitionOids != NIL && glob->parallelModeNeeded)
> > result->partitionOids = glob->partitionOids;
> >
> > (seems reasonable to me, as then it will match the condition for which
> > glob->partitionOids are added to glob->relationOids)
> >
> > then in plancache.c the check on parallelModeNeeded can be removed:
> >
> > /* Lock partitions ahead of modifying them in parallel mode. */
> > if (rti == resultRelation &&
> > plannedstmt->partitionOids != NIL)
> > AcquireExecutorLocksOnPartitions(plannedstmt->partitionOids,
> > rte->rellockmode, acquire);
> >
> > Let me know if this matches what you were thinking.
> >
>
> Yes, that is what I was thinking. But I have another question as well
> regarding tracking these partitions at two places (once in
> plannedstmt->relationOids and the second time in
> plannedstmt->partitionOids). I think it is better if you can prepare a
> patch with all the comments raised till now leaving this last question
> aside.
>

Posting an updated set of patches, that I believe address all the
recent feedback...

Regards,
Greg Nancarrow
Fujitsu Australia