On Wed, Dec 23, 2020 at 1:45 PM Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> On Wed, Dec 23, 2020 at 7:52 AM Hou, Zhijie <houzj.f...@cn.fujitsu.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?
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;
+ }
}
Regards,
Greg Nancarrow
Fujitsu Australia
