[
https://issues.apache.org/jira/browse/JENA-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965993#comment-13965993
]
ASF subversion and git services commented on JENA-615:
------------------------------------------------------
Commit 1586503 from [email protected] in branch 'jena/trunk'
[ https://svn.apache.org/r1586503 ]
Add documentation to TransformFilterInequality describing why it is off by
default and how to enable it where desired (JENA-615)
> Possible optimisation for FILTER(?var != <constant>)
> ----------------------------------------------------
>
> Key: JENA-615
> URL: https://issues.apache.org/jira/browse/JENA-615
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Priority: Minor
> Labels: algebra, optimization, sparql
> Attachments: inequality_bsbm_1M.csv, inequality_bsbm_1M.txt,
> inequality_lubm0.csv, inequality_lubm0.txt, inequality_sp2b_10k.csv,
> inequality_sp2b_10k.txt, inequality_sp2b_250k.csv, inequality_sp2b_250k.txt,
> inequality_sp2b_50k.csv, inequality_sp2b_50k.txt
>
>
> I have an idea for a possible optimisation for queries of the following
> general form:
> {noformat}
> SELECT *
> WHERE
> {
> # Some Patterns
> FILTER(?var != <http://constant>)
> }
> {noformat}
> This pattern crops up surprisingly often in real SPARQL workloads since it is
> often used to either limit a variable to exclude certain possibilities or to
> avoid self referential links in the data.
> In some cases it seems like this could be safely rewritten as follows:
> {noformat}
> SELECT *
> WHERE
> {
> # Some Patterns
> MINUS { BIND(<http://constant> AS ?var) }
> }
> {noformat}
> Or perhaps in a more generalised form like so:
> {noformat}
> SELECT * WHERE
> {
> # Some patterns
> MINUS { VALUES ?var { <http://constant/1> <http://constant/2> } }
> }
> {noformat}
> Which would nicely deal with the case of stating that a variable is not equal
> to multiple constant values.
> As I pointed out earlier this would not apply in every case, specifically I
> think at least the following must be true:
> - The variable must be guaranteed to be bound (similar to existing filter
> equality and implicit join optimisations)
> There is also the potential to spot cases where the variable will always be
> unbound and thus the expression is always an error and replace the entire
> sub-tree with {{table empty}} as we already do for equality and implicit join
> filters.
> I plan on taking a look at implementing this in the new year, if anyone has
> any thoughts on this (especially wrt to restrictions that should apply to
> when the optimisation is considered safe) then please comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
