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

> > And there seems another solution for this:
> >
> > In the patch, We only use the { ii_Expressions , ii_NumIndexAttrs ,
> > ii_IndexAttrNumbers } from the IndexInfo, which seems can get from
> "Relation-> rd_index".
> >
> > Based on above, May be we do not need to call BuildIndexInfo to build
> the IndexInfo.
> > It can avoid some unnecessary cost.
> > And in this solution we do not need to remove expression_planner.
> >
>
> Hmmm, when I debugged my simple test case, I found rel->rd_index was NULL,
> so it seems that the call to BuildIndexInfo is needed.
> (have I understood your suggestion correctly?)
>

Hi greg,

Thanks for debugging this.

May be I missed something. I am not sure about the case when rel->rd_index was NULL.
Because, In function BuildIndexInfo, it seems does not have NULL-check for index->rd_index.
Like the following:
----
BuildIndexInfo(Relation index)
{
IndexInfo *ii;
Form_pg_index indexStruct = index->rd_index;
int i;
int numAtts;

/* check the number of keys, and copy attr numbers into the IndexInfo */
numAtts = indexStruct->indnatts;
----

And the patch do not have NULL-check for index->rd_index too.
So I thought we can assume index->rd_index is not null, but it seems I may missed something ?

Can you please share the test case with me ?

I use the following code to replace the call of BuildIndexInfo.
And the installcheck passed.

Example:
+ Form_pg_index indexStruct = index_rel->rd_index;
+ List *ii_Expressions = RelationGetIndexExpressions(index_rel);
+ int ii_NumIndexAttrs = indexStruct->indnatts;
+ AttrNumber ii_IndexAttrNumbers[INDEX_MAX_KEYS];

+ for (int i = 0; i < ii_NumIndexAttrs; i++)
+ ii_IndexAttrNumbers[i] = indexStruct->indkey.values[i];

Best regards,
houzj