[
https://issues.apache.org/jira/browse/JENA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438966#comment-13438966
]
Simon Helsen commented on JENA-294:
-----------------------------------
yes, I saw this. Ok, in this case, it would be trivial since
SELECT *
{
?x :p ?o2
OPTIONAL { ?x :q ?o }
FILTER(?x = :x)
}
is equivalent to
SELECT *
{
OPTIONAL { ?x :q ?o }
FILTER(?x = :x)
?x :p ?o2
}
(I can provide a patch, but does that help here?)
Ok, I see the tests in TestFilterTransform. I assume the exact test for this
particular use-case depends a bit on how it is fixed. One possibility (but I
don't know if that could affect performance in other ways) is to always move
all non-OPTIONAL constraints before OPTIONAL constraints and then let
TransformFilterEquality do its normal job.
> 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
