Hello, I could not find the way to unregister from this mailing-list. Could you please remove my email address from mailing list ?
Thanks in advance, Laurent MARTIN 2014/1/7 Rob Vesse (JIRA) <[email protected]> > > [ > https://issues.apache.org/jira/browse/JENA-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Rob Vesse updated JENA-615: > --------------------------- > > Attachment: inequality_sp2b_250k.txt > inequality_sp2b_250k.csv > inequality_sp2b_50k.txt > inequality_sp2b_50k.csv > inequality_sp2b_10k.txt > inequality_sp2b_10k.csv > inequality_lubm0.txt > inequality_lubm0.csv > inequality_bsbm_1M.txt > inequality_bsbm_1M.csv > > Result files for the results discussed in prior comments > > > 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.1.5#6160) >
