Lava operators

Lava query plans are built of Lava operators. Each Lava operator is a self-contained software object that implements one of the basic physical operations that the optimizer uses to build query plans. Each Lava operator has five methods that can be called by its parent operator. These five methods correspond to the five phases of query execution:

Acquire
Open
Next
Close,
Release

Because the Lava operators all provide the same methods (that is, the same API), they can be interchanged like building blocks in a Lava query plan. For example, you can replace the NLJoin operator in Figure 1-2 with a MergeJoin operator or a HashJoin operator without impacting any of the other three operators in the query plan.

The Lava operators that can be chosen by the optimizer to build Lava query plans are listed in Table 1-3:

**Table 1-3: Lava operators**
Operator	Description
BulkOp	Executes the part of bcp processing that is done in the Lava query engine. Only found in query plans that are created by the bcp utility, not those created by the optimizer.
CacheScanOp	Reads rows from an in-memory table.
DelTextOp	Deletes text page chains as part of alter table drop column processing.
DeleteOp	Deletes rows from a local table.Deletes rows from a proxy table when the entire SQL statement cannot be shipped to the remote server. See also RemoteScanOp.
EmitOp (RootOp)	Routes query execution result rows. Can send results to the client or assign result values to local variables or fetch into variables. An EmitOp is always the top operator in a Lava query plan.
EmitExchangeOp	Routes result rows from a subplan that is executed in parallel to the ExchangeOp in the parent plan fragment. EmitExchangeOp always appears directly under an ExchangeOp. See Chapter 5, “Parallel Query Processing.”
GroupSortedOp (Aggregation)	Performs vector aggregation (group by) when the input rows are already sorted on the group-by columns. See also HashVectorAggOp.
GroupSorted (Distinct)	Eliminates duplicate rows. Requires the input rows to be sorted on all columns. See also HashDistinctOp and SortOp (Distinct).
HashVectorAggOp	Performs vector aggregation (group by). Uses a Hash algorithm to group the input rows, so no requirements on ordering of the input rows. See also GroupSortedOp (Aggregation).
HashDistinctOp	Eliminates duplicate rows using a hashing algorithm to find duplicate rows. See also GroupSortedOp (Distinct) and SortOp (Distinct).
HashJoinOp	Performs a join of two input row streams using the HashJoin algorithm.
HashUnionOp	Performs a union operation of two or more input row streams using a hashing algorithm to find and eliminate duplicate rows. See also MergeUnionOp and UnionAllOp.
InsScrollOp	Implements extra processing needed to support insensitive scrollable cursors. See also SemiInsScrollOp.
InsertOp	Inserts rows to a local table.Inserts rows to a proxy table when the entire SQL statement cannot be shipped to the remote server. See also RemoteScanOp.
MergeJoinOp	Performs a join of two streams of rows that are sorted on the joining columns using the mergejoin algorithm.
MergeUnionOp	Performs a union or union all operation on two or more sorted input streams. Guarantees that the output stream retains the ordering of the input streams. See also HashUnionOp and UnionAllOp.
NestedLoopJoinOp	Performs a join of two input streams using the NestedLoopJoin algorithm.
NaryNestedLoopJoinOp	Performs a join of three or more input streams using an enhanced NestedLoopJoin algorithm. This operator replaces a left-deep tree of NestedLoopJoin operators and can lead to significant performance improvements when rows of some of the input streams can be skipped.
OrScanOp	Inserts the in or or values into an in-memory table, sorts the values, and removes the duplicates.Then returns the values, one at a time. Only used for SQL statements with in clauses or multiple or clauses on the same column.
PtnScanOp	Reads rows from a local table (partitioned or not) using either a table scan or an index scan to access the rows.
RIDJoinOp	Receives one or more row identifiers (RIDs) from its left-child operator and calls on its right-child operator (PtnScanOp) to find the corresponding rows. Used only on SQL statements with or clauses on different columns of the same table.
RIFilterOp (Direct)	Drives the execution of a subplan to enforce referential integrity constraints that can be checked on a row-by-row basis.Appears only in insert, delete, or update queries on tables with referential integrity constraints.
RIFilterOp (Deferred)	Drives the execution of a sub-plan to enforce referential integrity constraints that can only be checked after all rows that are affected by the query have been processed.
RemoteScanOp	Accesses proxy tables. The RemoteScanOp can: Read rows from a single proxy table for further processing in a Lava query plan on the local host. Pass complete SQL statements to a remote host for execution: insert, delete, update, and select statements. In this case, the Lava query plan consists of an EmitOp with a RemoteScanOp as its only child operator. Pass an arbitrarily complex query plan fragment to a remote host for execution and read in the result rows (function shipping).
RestrictOp	Evaluates expressions.
SQFilterOp	Drives the execution of a subplan to execute one or more subqueries.
ScalarAggOp	Performs scalar aggregation, such as aggregates without group by.
SemiInsScrollOp	Performs extra processing to support semi-insensitive scrollable cursors. See also InsScrollOp.
SequencerOp	Enforces sequential execution of different sub-plans in the query plan.
SortOp	Sorts its input rows based upon specified keys.
SortOp (Distinct)	Sorts its input and removes duplicate rows. See also HashDisitnctOp and GroupSortedOp (Distinct).
StoreOp	Creates and coordinates the filling of a worktable, and creates a clustered index on the worktable if required. StoreOp can only have an InsertOp as a child; the InsertOp populates the worktable.
UnionAllOp	Performs a union all operation on two or more input streams. See also HashUnionOp and MergeUnionOp.
UpdateOp	Changes the value of columns in rows of a local table or of a proxy table when the entire update statement cannot be sent to the remote server. See also RemoteScanOp.
ExchangeOp	Enables and coordinates parallel execution of Lava query plans. The ExchangeOp can be inserted between almost any two Lava operators in a query plan to divide the plan into sub-plans that can be executed in parallel. See Chapter 5, “Parallel Query Processing.”