Rob Vesse created JENA-615:
------------------------------
Summary: 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
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.1.5#6160)
