[
https://issues.apache.org/jira/browse/JENA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434589#comment-13434589
]
Simon Helsen commented on JENA-294:
-----------------------------------
ah, I see now, it seems that the expansion (substitute) should take place
regardless, but the assignment should only happen if the conditional evaluates
to something. So it should be pushed inside and I see now that this is what you
were saying in one of the comments above.
Btw, the reason our example does not fail is that the WHERE clause also has a
non-optional condition on the filter variable, so even if the optional does not
match, the assignment is always correct.
I am attaching a new patch. If an assignment sits on a conditional or leftJoin,
it shifts it inside the RHS. Now, I must say I am not entirely sure how nested
conditionals are evaluated, so perhaps this is not quite right. E.g. I am
wondering if the assignment should also be pushed into the LHS and then
recursively down. The substitution itself is not affected I'd say and the
precondition check remains the same as well because a LHS in these left joins
which is a unit does not.
So, e.g. query
PREFIX : <http://example/>
SELECT *
{
OPTIONAL { ?x :p ?z }
OPTIONAL { ?y :q ?z }
FILTER(?z = :a)
}
turns into
(prefix ((: <http://example/>))
(conditional
(conditional
(table unit)
(bgp (triple ?x :p :a)))
(assign ((?z :a))
(bgp (triple ?y :q :a)))))
but query
PREFIX : <http://example/>
SELECT *
{
OPTIONAL { ?x :p ?z }
OPTIONAL { ?y :q ?z }
?w :r ?z
FILTER(?z = :a)
}
(which is more like our use case right now) produces this plan:
(prefix ((: <http://example/>))
(assign ((?z :a))
(sequence
(conditional
(conditional
(table unit)
(bgp (triple ?x :p :a)))
(bgp (triple ?y :q :a)))
(bgp (triple ?w :r :a)))))
and your example
PREFIX : <http://example/>
SELECT *
{
OPTIONAL { ?x :q ?o }
FILTER(?x = :x)
}
produces plan
(prefix ((: <http://example/>))
(conditional
(table unit)
(assign ((?x :x))
(bgp (triple :x :q ?o)))))
> TransformFilterEquality does not handle starting OPTIONAL well
> --------------------------------------------------------------
>
> Key: JENA-294
> URL: https://issues.apache.org/jira/browse/JENA-294
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: Jena 2.7.4
> Reporter: Simon Helsen
> Attachments: patch.txt
>
>
> There was one other case where our tests were stuck on a very slow query
> execution because transformFilterEquality failed to optimize. The problem is
> that the optimizer gives up whenever the WHERE clause starts with an OPTIONAL
> clause. The reason is that the generated algebraic formula starts with a
> TableUnit and this is not handled correctly.
> I have attached a patch which fixes the problem
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
