The NIL operator is a unary operator that performs no action. It is simply used to as the root node of query plans.

The SELECT operator is a unary operator and is configured with a predicate containing an expression. Example expressions include "age < 20" and "table1.age < table2.maxAge".

The PROJECT operator is unary operator and is configured with ordered list of arithmetic expressions that define the output attributes.

The RENAME operator is a unary operator and is configured with a map to convert input attribute names to output attribute names.

The DUPLICATE_ELIMINATION operator in a unary operator that eliminates duplicate tuples.

The SORT operator is a unary operator and is configured with a ordered list of attributes on which the sorting is to be performed. Note that the operator does not currently supporting specifying ascending or descending sorting on each attribute. All sorting is currently ascending.

The TABLE_SCAN operator is a unary operator that represents query that is sent to a data source. Initially all TABLE_SCAN operators are constructed with the name of single table to be scanned. This easily maps into a SQL query to be sent to the database. For example, if the table is myTable then the SQL query is

  SELECT * FROM myTable

An essential optimisation strategy used by DQP is to push as many of the operators as possible into the queries that are sent to the database. For example, if a TABLE_SCAN operator is followed by a SELECT operator with expression "age < 20" then DQP will try to push the functionality of the SELECT operator into the TABLE_SCAN operator and remove the SELECT operator. In our example this would mean that the TABLE_SCAN operator's SQL query would now be

SELECT * FROM myTable WHERE age < 20

Other operators such as PROJECT and INNER_THETA_JOIN can also be pushed into the SQL query where appropriate.

The TABLE_SCAN operator therefore holds a SQL query that is sent to the database rather than just a the name of a single table to be scanned. Many operators can be pushed into a TABLE_SCAN operator. For more information see Section 135.3.11, “Table Scan Implosion Optimiser”.

The GROUP_BY operator is a unary operator that groups tuples and possibly also computes aggregation functions on these groups. It is configured with a list of attributes on which to group and a list of aggregation functions to apply. The aggregation functions include the arithmetic expressions that provide the arguments to these functions. For example, if width and height are attributes of the incoming tuples then the following are example of function definitions:

The SCALAR_GROUP_BY operator is a unary operator that performs aggregations when the query has no group-by clause. It is configured with a list of aggregation functions to apply. The aggregation functions include the arithmetic expressions that provide the arguments to this functions. For example, if width and height are attributes of the incoming tuples then the following are example of function definitions:

The ONE_ROW_ONLY operator is a unary operator that is used detect illegal subqueries which were expected to produce a scalar result. User errors of this kind can only be detected at runtime.

The PRODUCT operator is a binary operator that performs a product of its two inputs. At execution time the default implementation is to store the data in the second (right hand) child and stream the data in the first (left hand) child.

The INNER_THETA_JOIN operator is a binary operator that performs an inner theta join of its two inputs. It is configured with a predicate that relates attributes from one side of the join with attributes from the other.

The FULL_OUTER_JOIN operator is a binary operator that performs a full outer join of its two inputs. It is configured with a predicate that relates attributes from one side of the join with attributes from the other.

The RIGHT_OUTER_JOIN operator is a binary operator that performs an right outer join of its two inputs. It is configured with a predicate that relates attributes from one side of the join with attributes from the other.

The LEFT_OUTER_JOIN operator is a binary operator that performs an left outer join of its two inputs. It is configured with a predicate that relates attributes from one side of the join with attributes from the other.

The SEMI_JOIN operator is a binary operator that performs an semi join of its two inputs. It is configured with a predicate that related attributes from one side of the join with attributes from the other.

The SEMI_JOIN operator is a binary operator that performs an semi join of its two inputs. It is configured with a predicate that related attributes from one side of the join with attributes from the other.

The UNION operator is a binary operator that performs a union of its two inputs. The operator can be configured to be specify either a set union (where duplicates are eliminated) or a bag union (where duplicates are permitted).

The INTERSECTION operator is a binary operator that performs an intersection of its two inputs. The operator can be configured to be specify either a set intersection (where duplicates are eliminated) or a bag intersection (where duplicates are permitted).

The DIFFERENCE operator is a binary operator that performs a difference of its two inputs. The operator can be configured to be specify either a set difference (where duplicates are eliminated) or a bag difference (where duplicates are permitted).

	Warning
	This version of DQP is unable to execute queries that require the APPLY operator. DQP will fail to find a builder class that maps the APPLY operator into an implementation built from OGSA-DAI activities.

The APPLY operator is a binary operator used for correlated sub-queries. It is configured with a set of attributes to bind and also a join operator that defines the join type operation that is correlated.

The APPLY operator abstracts "for each" functionality and parameterise relational expression invocation. The following query plan

(APPLY R E(r))

means: for each tuple r from R execute relational expression E on r. The result of the invocation is joined with tuple r using an arbitrary join logic. The join logic is a parameter of the APPLY operator:

(APPLY[INNER_THETA_JOIN] R E(r))

Usually only a subset of attributes from r is needed to execute a parameterised relational expression. A set of attributes to bind is another parameter of the APPLY operator:

(APPLY[INNER_THETA_JOIN; {a.id, a.eid}] R E(a.id, a.eid))

The APPLY operator appears in query plans compiled for queries with correlated subqueries. For example

SELECT e.fname, e.lname
FROM employee e
WHERE EXISTS
     (SELECT * FROM dependent d WHERE e.ssn = d.essn)

will be compiled to

(PROJECT[e.fname, e.lname]
 (APPLY[INNER_THETA_JOIN[e.ssn = d.essn]; {e.ssn}]
   (RENAME[employee->e]
     (TABLE_SCAN employee)
   )
   (RENAME[dependent->d]
     (TABLE_SCAN dependent)
   )
 )
) 

The FILTERED_TABLE_SCAN operator is a unary operator that is used to represent table scans which are parameterised during run time with attribute values or ranges coming from another branch of the query plan. FILTERED_TABLE_SCAN operators are constructed from a TABLE_SCAN operator and a predicate that restricts the tuples to be produced.

FILTERED_TABLE_SCAN operators are never used in the initial query plan but can be inserted instead to replace a TABLE_SCAN operator by the filtered table scan optimiser (see Section 135.3.12, “Filtered Table Scan Optimiser”) when doing so is likely to make a significant performance improvement.

The QUERY_APPLY operator binary operator that is a special kind of apply operator which parameterises one query branch with values from the other branch. It is different from the conventional APPLY operator in that the parameter set is extracted from the entire tuple stream and not on a per tuple basis. The parameterised branch is executed only once. The stream which provided parameters and the parameterised stream are joined using the logic of an embedded binary operator. This operator is usually used with a FILTERED_TABLE_SCAN operator.

The EXCHANGE operator is a unary operator that is added to the query plan at any point where data must be moved from one evaluation node (OGSA-DAI server) to another.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.

This section of the documentation has not yet been written. Please see the online version which may be more up to date.