This handles a VALUES clause. It grabs the binding sets from the
BindingsClause, attach them to the query as a named subquery with a hash
index, and then add a named subquery include to the pipeline right here.
The VALUES are interpreted using a solution set hash join. The "plan" for
the hash join of the VALUES with the solutions flowing through the
pipeline is: (a) we take the IBindingSet[] and use a
HashIndexOpto generate the hash index; and (b) we use a
SolutionSetHashJoinOp to join the solutions from the pipeline
with those in the hash index. Both JVM and HTree versions of this plan
are supported.
1.
HashIndexOp (JVM or HTree): Specify the IBindingSet[] as the
source. When the HashIndexOp runs, it will build a hash index from the
IBindingSet[].
Note: The join variables need to be set based on the known bound
variables in the context where we will evaluate the solution set hash
join (head of the sub-SELECT, OPTIONAL) and those that are bound by the
solution set hash join.
Note: The static analysis code needs to examine the definitely, and maybe
produced bindings for the
BindingsClause. See the
ISolutionSetStats interface and
SolutionSetStatserator#get(IBindingSet[]) for a convenience
method.
2.
SolutionSetHashJoinOp (JVM or HTree): Joins the solutions
flowing into the sub-query or update with the solutions from the
HashIndexOp. This will take each solution from the pipeline, probe the
hash index for solutions specified by the VALUES clause, and then do a
JOIN for each such solution that is discovered.