[
https://issues.apache.org/jira/browse/JENA-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13864203#comment-13864203
]
Andy Seaborne commented on JENA-615:
------------------------------------
Both {{FILTER}} and {{MINUS}} end up as very similar looking loops on the
incoming stream. With the new index table for {{MINUS}}, maybe it's because
{{FILTER}} has some fixed overhead either due to lack of code refinement or
that it does a general dispatch on {{=}}. A {{FILTER}} of {{sameTerm}} might be
a touch faster, but that still generates a {{NodeValue}}. If you get the
chance, could you profile the code to see where the CPU is going?
> 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
>
> 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)
