Class ImplicitJoinOptimiser

An Algebra Optimiser which implements the Implicit Join optimisation.

Inheritance
System.Object
ImplicitJoinOptimiser
Implements
Inherited Members
object.Equals(object)
object.Equals(object, object)
object.GetHashCode()
object.GetType()
object.MemberwiseClone()
object.ReferenceEquals(object, object)
object.ToString()
Namespace: VDS.RDF.Query.Optimisation
Assembly: dotNetRdf.dll
Syntax
public class ImplicitJoinOptimiser : IAlgebraOptimiser
Remarks

An implict join is implied by a query like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?y a ?type .
  FILTER (?x = ?y) .
}

Such queries can be very expensive to calculate, the implict join optimisation attempts to substitute one variable for the other and use a BIND to ensure both variables are visible outside of the graph pattern affected i.e. the resulting query looks like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?x a ?type .
  BIND (?x AS ?y)
}

Under normal circumstances this optimisation is only used when the implict join is denoted by a SAMETERM expression or the optimiser is sure the variables don't represent literals (they never occur in the Object position) since when value equality is involved substituing one variable for another changes the semantics of the query and may lead to unexpected results. Since this optimisation may offer big performance benefits for some queries (at the cost of potentially incorrect results) this form of the optimisation is allowed when you explicitly request it in the constructor of this class.

This optimiser is also capable of generating special algebra to deal with the case where there is an implicit join but the substitution based optimisation does not apply because variables cannot be substituted into the inner algebra, in this case a FilteredProduct is generated instead.

Constructors

| Improve this Doc View Source

ImplicitJoinOptimiser()

Create a new ImplicitJoinOptimiser instance.

Declaration
public ImplicitJoinOptimiser()
Remarks

An implict join is implied by a query like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?y a ?type .
  FILTER (?x = ?y) .
}

Such queries can be very expensive to calculate, the implict join optimisation attempts to substitute one variable for the other and use a BIND to ensure both variables are visible outside of the graph pattern affected i.e. the resulting query looks like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?x a ?type .
  BIND (?x AS ?y)
}

Under normal circumstances this optimisation is only used when the implict join is denoted by a SAMETERM expression or the optimiser is sure the variables don't represent literals (they never occur in the Object position) since when value equality is involved substituing one variable for another changes the semantics of the query and may lead to unexpected results. Since this optimisation may offer big performance benefits for some queries (at the cost of potentially incorrect results) this form of the optimisation is allowed when you explicitly request it in the constructor of this class.

This optimiser is also capable of generating special algebra to deal with the case where there is an implicit join but the substitution based optimisation does not apply because variables cannot be substituted into the inner algebra, in this case a FilteredProduct is generated instead.

Properties

| Improve this Doc View Source

UnsafeOptimisation

Get or set the flag that controls whether this class will allow the optimization to be applied when there is a possibility that the join terms are literals.

Declaration
public bool UnsafeOptimisation { get; set; }
Property Value
Type Description
System.Boolean
Remarks

An implict join is implied by a query like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?y a ?type .
  FILTER (?x = ?y) .
}

Such queries can be very expensive to calculate, the implict join optimisation attempts to substitute one variable for the other and use a BIND to ensure both variables are visible outside of the graph pattern affected i.e. the resulting query looks like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?x a ?type .
  BIND (?x AS ?y)
}

Under normal circumstances this optimisation is only used when the implict join is denoted by a SAMETERM expression or the optimiser is sure the variables don't represent literals (they never occur in the Object position) since when value equality is involved substituing one variable for another changes the semantics of the query and may lead to unexpected results. Since this optimisation may offer big performance benefits for some queries (at the cost of potentially incorrect results) this form of the optimisation is allowed when you explicitly request it in the constructor of this class.

This optimiser is also capable of generating special algebra to deal with the case where there is an implicit join but the substitution based optimisation does not apply because variables cannot be substituted into the inner algebra, in this case a FilteredProduct is generated instead.

Methods

| Improve this Doc View Source

IsApplicable(SparqlQuery)

Returns that this optimiser is applicable to all queries.

Declaration
public bool IsApplicable(SparqlQuery q)
Parameters
Type Name Description
SparqlQuery q

Query.
Returns
Type Description
System.Boolean
Remarks

An implict join is implied by a query like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?y a ?type .
  FILTER (?x = ?y) .
}

Such queries can be very expensive to calculate, the implict join optimisation attempts to substitute one variable for the other and use a BIND to ensure both variables are visible outside of the graph pattern affected i.e. the resulting query looks like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?x a ?type .
  BIND (?x AS ?y)
}

Under normal circumstances this optimisation is only used when the implict join is denoted by a SAMETERM expression or the optimiser is sure the variables don't represent literals (they never occur in the Object position) since when value equality is involved substituing one variable for another changes the semantics of the query and may lead to unexpected results. Since this optimisation may offer big performance benefits for some queries (at the cost of potentially incorrect results) this form of the optimisation is allowed when you explicitly request it in the constructor of this class.

This optimiser is also capable of generating special algebra to deal with the case where there is an implicit join but the substitution based optimisation does not apply because variables cannot be substituted into the inner algebra, in this case a FilteredProduct is generated instead.

| Improve this Doc View Source

IsApplicable(SparqlUpdateCommandSet)

Returns that this optimiser is applicable to all updates.

Declaration
public bool IsApplicable(SparqlUpdateCommandSet cmds)
Parameters
Type Name Description
SparqlUpdateCommandSet cmds

Updates.
Returns
Type Description
System.Boolean
Remarks

An implict join is implied by a query like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?y a ?type .
  FILTER (?x = ?y) .
}

Such queries can be very expensive to calculate, the implict join optimisation attempts to substitute one variable for the other and use a BIND to ensure both variables are visible outside of the graph pattern affected i.e. the resulting query looks like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?x a ?type .
  BIND (?x AS ?y)
}

Under normal circumstances this optimisation is only used when the implict join is denoted by a SAMETERM expression or the optimiser is sure the variables don't represent literals (they never occur in the Object position) since when value equality is involved substituing one variable for another changes the semantics of the query and may lead to unexpected results. Since this optimisation may offer big performance benefits for some queries (at the cost of potentially incorrect results) this form of the optimisation is allowed when you explicitly request it in the constructor of this class.

This optimiser is also capable of generating special algebra to deal with the case where there is an implicit join but the substitution based optimisation does not apply because variables cannot be substituted into the inner algebra, in this case a FilteredProduct is generated instead.

| Improve this Doc View Source

Optimise(ISparqlAlgebra)

Optimises the Algebra to use implicit joins where applicable.

Declaration
public ISparqlAlgebra Optimise(ISparqlAlgebra algebra)
Parameters
Type Name Description
ISparqlAlgebra algebra

Algebra.
Returns
Type Description
ISparqlAlgebra
Remarks

An implict join is implied by a query like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?y a ?type .
  FILTER (?x = ?y) .
}

Such queries can be very expensive to calculate, the implict join optimisation attempts to substitute one variable for the other and use a BIND to ensure both variables are visible outside of the graph pattern affected i.e. the resulting query looks like the following: 

SELECT *
WHERE
{
  ?x a ?type .
  ?x a ?type .
  BIND (?x AS ?y)
}

Under normal circumstances this optimisation is only used when the implict join is denoted by a SAMETERM expression or the optimiser is sure the variables don't represent literals (they never occur in the Object position) since when value equality is involved substituing one variable for another changes the semantics of the query and may lead to unexpected results. Since this optimisation may offer big performance benefits for some queries (at the cost of potentially incorrect results) this form of the optimisation is allowed when you explicitly request it in the constructor of this class.

This optimiser is also capable of generating special algebra to deal with the case where there is an implicit join but the substitution based optimisation does not apply because variables cannot be substituted into the inner algebra, in this case a FilteredProduct is generated instead.

Implements

Extension Methods