[
https://issues.apache.org/jira/browse/JENA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438822#comment-13438822
]
Andy Seaborne commented on JENA-294:
------------------------------------
I discovered a completely different approach which pushes in assigns but also
retains the filter in case it is still needed. The processing is still much
more efficient. Filters are quite cheap to execute - the optimization is to
reduce the unnecessary returns from the sub-expressions.
Please try out tonight's dev build.
For the last example:
(filter (= ?x :x)
(conditional
(conditional
(table unit)
(assign ((?x :x))
(bgp (triple :x :q ?o))))
(assign ((?x :x))
(bgp (triple :x :r ?s)))))
> 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: jena-294-afs-1.patch, patch.txt, patch.txt,
> test-filter-equality.zip
>
>
> 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
