I've already emailed you this once but to re-iterate See http://www.apache.org/foundation/mailinglists.html which explains how to subscribe and unsubscribe from any Apache mailing list
Specifically you want to unsubscribe from [email protected] Rob On 08/01/2014 09:24, "Laurent Martin" <[email protected]> wrote: >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.pl >>ugin.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) >>
