Click or drag to resize

ParallelEvaluationOptimiser Class

An Algebra Optimiser which looks for unions and joins that can be evaluated in parallel to improve query evaluation speed in some cases.
Inheritance Hierarchy

Namespace:  VDS.RDF.Query.Optimisation
Assembly:  dotNetRDF (in dotNetRDF.dll) Version:
public class ParallelEvaluationOptimiser : IAlgebraOptimiser

The ParallelEvaluationOptimiser type exposes the following members.

Public methodParallelEvaluationOptimiser
Initializes a new instance of the ParallelEvaluationOptimiser class
Public methodEquals
Determines whether the specified object is equal to the current object.
(Inherited from Object.)
Protected methodFinalize
Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.
(Inherited from Object.)
Public methodGetHashCode
Serves as the default hash function.
(Inherited from Object.)
Public methodGetType
Gets the Type of the current instance.
(Inherited from Object.)
Public methodIsApplicable(SparqlQuery)
Returns that the optimser is applicable to all queries.
Public methodIsApplicable(SparqlUpdateCommandSet)
Returns that the optimiser is not applicable to updates.
Protected methodMemberwiseClone
Creates a shallow copy of the current Object.
(Inherited from Object.)
Public methodOptimise
Optimises the algebra to use parallelised variants of Join and Union where possible.
Public methodToString
Returns a string that represents the current object.
(Inherited from Object.)

Using this feature allows you to use experimental parallel SPARQL evaluation optimisations which may improve query evaluation speed for some queries. A query must either use UNION or have joins which are disjoint in order for any parallel evaluation to take place.

Users should be aware that using this optimiser may actually increase evaluation speed in some cases e.g. where either side of a disjoint join will return empty especially when it is the left hand side that will do so.

Also note that while use of this optimiser should not cause queries to return incorrect results as it does not change the semantics of the evaluation as it only parallelises independent operators we cannot guarantee that all parallelised queries will return identical results to their non-parallelised counterparts. If you find a query that you believe is giving incorrect results when used with this optimiser please test without the optimiser enabled to check that the apparent incorrect result is not an artifact of this optimisation.

See Also