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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Greg Nancarrow <gregn4422(at)gmail(dot)com>
Cc: "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Date: 2021-01-21 08:30:33
Message-ID: CAA4eK1JSBWTvzaac0+LrbPoT-4GGiDsw2r=0gn=Gb1+J-qJv7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 21, 2021 at 12:44 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> On Wed, Dec 23, 2020 at 1:45 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, Dec 23, 2020 at 7:52 AM Hou, Zhijie <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> wrote:
> > >
> > > Hi
> > >
> > > > > I may be wrong, and if I miss sth in previous mails, please give me some
> > > > hints.
> > > > > IMO, serial insertion with underlying parallel SELECT can be
> > > > > considered for foreign table or temporary table, as the insertions only
> > > > happened in the leader process.
> > > > >
> > > >
> > > > I don't think we support parallel scan for temporary tables. Can you please
> > > > try once both of these operations without Insert being involved? If you
> > > > are able to produce a parallel plan without Insert then we can see why it
> > > > is not supported with Insert.
> > >
> > > Sorry, may be I did not express it clearly, I actually means the case when insert's target(not in select part) table is temporary.
> > > And you are right that parallel select is not enabled when temporary table is in select part.
> > >
> >
> > I think Select can be parallel for this case and we should support this case.
> >
>
> So I think we're saying that if the target table is a foreign table or
> temporary table, it can be regarded as PARALLEL_RESTRICTED, right?
>

Yes.

> i.e. code-wise:
>
> /*
> - * We can't support table modification in parallel-mode if
> it's a foreign
> - * table/partition (no FDW API for supporting parallel access) or a
> + * We can't support table modification in a parallel worker if it's a
> + * foreign table/partition (no FDW API for supporting parallel
> access) or a
> * temporary table.
> */
> if (rel->rd_rel->relkind == RELKIND_FOREIGN_TABLE ||
> RelationUsesLocalBuffers(rel))
> {
> - table_close(rel, lockmode);
> - context->max_hazard = PROPARALLEL_UNSAFE;
> - return true;
> + if (max_parallel_hazard_test(PROPARALLEL_RESTRICTED, context))
> + {
> + table_close(rel, lockmode);
> + return true;
> + }
> }
>

Yeah, these changes look correct to me.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Shinderuk 2021-01-21 08:39:48 Re: [PATCH 1/1] Fix detection of pwritev support for OSX.
Previous Message Kyotaro Horiguchi 2021-01-21 08:30:09 Re: [HACKERS] make async slave to wait for lsn to be replayed