Details
-
Type:
Sub-task
-
Status: Done
-
Priority:
Highest
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: BLAZEGRAPH_RELEASE_1_5_2
-
Component/s: Query Plan Generator
-
Labels:None
Description
Insert one triple into a blaze instance with the text index enabled:
<:s> <:p> "foo" .
Then run the following query:
select ?o ?d
where {
service bds:search {
?o bds:search "foo" .
}
values (?d) {
(<:a>)
(<:b>)
(<:c>)
}
}
Results in:
Selection [ Bindings [o=foo,d=:a], Bindings [o=foo,d=:a], Bindings [o=foo,d=:a], Bindings [o=foo,d=:b], Bindings [o=foo,d=:b], Bindings [o=foo,d=:b], Bindings [o=foo,d=:c], Bindings [o=foo,d=:c], Bindings [o=foo,d=:c] ]
For some reason, two values gives you four results, three values gives you nine results, etc. We are getting a cross product.
Activity
Fixed in branch bindings-refactor, added ticket as a test case. Just re-running govtrack to get hints on performance regressions, once this succeeds the branch will be merged into master.
The fix was part of a major refactoring. The prior optimizers ASTSimpleBindingsOptimizer, ASTValuesOptimizer, and ASTBindingsAssigner were retired, and custom code for extracting static bindings (outside of optimizers) was eliminated. All cases were generalized in the ASTStaticBindingsOptimizer, which analyzes the query to detect statically derivable bindings introduced via constructs (such as BIND/VALUES, FILTER with sameTerm, IN or term equality over URIs). These bindings are pulled out to the top-level clause where valid (according to the bottom up semantics) and inlines them at various positions. The refactoring is backed by a broad set of test cases, including both SPARQL level and AST level tests.
You can fix this by re-formulating the query to include the values variable in the projection of the named subquery as follows:
select ?o ?d with { select ?o ?d { service bds:search { ?o bds:search "foo" . } } } as %search where { include %search . values (?d) { (<:a>) (<:b>) (<:c>) } }