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

On Wed, Oct 7, 2020 at 7:25 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> On Wed, Oct 7, 2020 at 12:40 AM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> > In parallel, we are not doing anything(due to the same reason
> > explained in above comment) to find whether there is a foreign
> > partition or not while deciding to go with parallel/non-parallel copy,
> > we are just throwing an error during the first tuple insertion into
> > the partition.
> >
> > errmsg("cannot perform PARALLEL COPY if partition has BEFORE/INSTEAD
> > OF triggers, or if the partition is foreign partition"),
> > errhint("Try COPY without PARALLEL option")));
> >
>
> I'm wondering whether code similar to the following can safely be used
> to detect a foreign partition:
>
> if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
> {
> int i;
> PartitionDesc pd = RelationGetPartitionDesc(rel);
> for (i = 0; i < pd->nparts; i++)
> {
> if (get_rel_relkind(pd->oids[i]) == RELKIND_FOREIGN_TABLE)
> {
> table_close(rel, NoLock);
> return false;
> }
> }
> }
>

Actually, the addition of this kind of check is still not good enough.
Partitions can have their own constraints, triggers, column default
expressions etc. and a partition itself can be partitioned.
I've written code to recursively walk the partitions and do all the
various checks for parallel-insert-safety as before, but it's doing a
fair bit of work.
Any other idea of dealing with this? Seems it can't be avoided if you
want to support partitioned tables and partitions.

Regards,
Greg Nancarrow
Fujitsu Australia