RE: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

> > 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