You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Rob Vesse (JIRA)" <ji...@apache.org> on 2014/01/07 17:25:52 UTC
[jira] [Updated] (JENA-615) Possible optimisation for FILTER(?var
!= )
[ 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)
Re: [jira] [Updated] (JENA-615) Possible optimisation for FILTER(?var
!= )
Posted by Laurent Martin <la...@gmail.com>.
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) <ji...@apache.org>
>
> [
> 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)
>