Our current UNION-based bind join algorithm (see PhysicalOpBindJoinWithUNION and ExecOpBindJoinSPARQLwithUNION) creates a UNION pattern with FILTERs added into each UNION part. That's unnecessarily complex for the accessed SPARQL endpoint because the given graph pattern before the FILTER is repeated within each of the UNION parts.
A better idea is to create a UNION pattern where each part of the UNION is a version of the given graph pattern in which the join variables have been substituted by applying one of the solutions of the current input batch. To be able to figure out which of the UNION parts a retrieved solution mapping comes from and, thus, to be able to figure out which of the input solutions the retrieved solution has to be joined with, each UNION part needs to be extended with a BIND clause of the form BIND( x AS ?cnt ) where ?cnt is a new variable (needs to be the same in all UNION parts) and x is an integer that is different for each UNION part.
Our current UNION-based bind join algorithm (see
PhysicalOpBindJoinWithUNIONandExecOpBindJoinSPARQLwithUNION) creates a UNION pattern with FILTERs added into each UNION part. That's unnecessarily complex for the accessed SPARQL endpoint because the given graph pattern before the FILTER is repeated within each of the UNION parts.A better idea is to create a UNION pattern where each part of the UNION is a version of the given graph pattern in which the join variables have been substituted by applying one of the solutions of the current input batch. To be able to figure out which of the UNION parts a retrieved solution mapping comes from and, thus, to be able to figure out which of the input solutions the retrieved solution has to be joined with, each UNION part needs to be extended with a BIND clause of the form
BIND( x AS ?cnt )where?cntis a new variable (needs to be the same in all UNION parts) andxis an integer that is different for each UNION part.