[
https://issues.apache.org/jira/browse/JENA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438829#comment-13438829
]
Simon Helsen commented on JENA-294:
-----------------------------------
right, the problem is that if the filters with the ?R=<uri> pattern are not
converted to assigns, we end up with potentially countless of returns which is
why we got the performance breakdown from a few ms to minutes. With the
assigns, the variable is not expanded and tested each time. What you suggest
makes sense. You introduce an assign for each occurrence of the variable (deep
down) and just keep the filter where it was originally to make sure the
semantics is correct (i.e. as before the optimization). I'll definitely check
it out
> 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
> Assignee: Andy Seaborne
> Fix For: ARQ 2.9.4
>
> 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
