rvesse commented on code in PR #1631:
URL: https://github.com/apache/jena/pull/1631#discussion_r1030190728
##########
jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/TransformFilterImplicitJoin.java:
##########
@@ -120,10 +120,14 @@ private static Op apply(ExprList exprs, Op subOp) {
// ---- Check if the subOp is the right shape to transform.
Op op = subOp;
- // Special case : deduce that the filter will always "eval unbound"
- // hence eliminate all rows. Return the empty table.
+ // LATERAL : This is not longer true.
+// // Special case : deduce that the filter will always "eval unbound"
+// // hence eliminate all rows. Return the empty table.
+// if (testSpecialCaseUnused(subOp, joins, remaining))
+// return OpTable.empty();
+ // But simply skipping this causes (filter) to become (assign) which
fails as (assign) does not handle errors.
if (testSpecialCaseUnused(subOp, joins, remaining))
- return OpTable.empty();
+ return null;
Review Comment:
Yes the bottom up property means the optimisation would be attempted but
then you could discard it when you reached the `OpLateral` level but that does
mean unnecessary work is done.
Having the walker be able to decide what operations to descend through could
be a useful mechanism in general for limiting the scope of transformations
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
