Neoview Query Guide (R2.3, R2.4, R2.5)

associated with the SPLIT_TOP operator. The SPLIT_TOP operator executes in either the master
executor or ESP process. It cannot execute in the DAM process.
Although not considered a process boundary operator, the SPLIT_TOP operator indicates that
the process needs to access more than one partition of a table through the PARTITION_ACCESS
operator. The access might be parallel. Additionally, the SPLIT_TOP operator can be present in
the master executor and ESP processes. It facilitates DAM parallelism and consolidates data.
The SPLIT_TOP operator always has a PARTITION_ACCESS operator as its child. The description
field for this operator contains:
Data TypeToken DescriptionToken
integerA sequential number assigned to the fragment. 0 is always master
executor and 1 is reserved for the Explain plan. Numbers 2 to n
will be ESP or DAM fragments.
fragment_id
integerThe fragment_id for the parent fragment of the current fragment.
Value is (none) for master executor.
parent_frag
textmaster, ESP, or DAMfragment_type
textIndicates whether an optimization for short, simple operations
is used. Value is used if this optimization is used.
olt_optimization
integerNumber of ESPs containing this operatorparent_processes
textType of top partitioning and contains summary information
about the parallel plan
parent_partitioning_function
integerNumber of bottom partitionschild_processes
textType of bottom partitioning and contains summary information
about the parallel plan
child_partitioning_function
textAssociates each process at the bottom to a CPUbottom_node_map
Understanding Joins
The Neoview database has three main join types: nested join, merge join, and hybrid hash join.
Within the join types, many join operators exist. The join types and operators that occur within
each type are described in this subsection.
All joins are binary, work with two tables and result sets at a time, and are distinguished by a
left side (also called the outer table/result set) and right side (also called the inner table/result
set). Although the steps that process the join might be quite complex, all joins work with two
sides only.
As joins are processed in the query execution plan, the join results flow from the join to the next
operator, which can be in the same or a different process. A single process can include many
joins, one supplying another with source rows. All joins can be processed in parallel by ESPs.
Parallel joins can be against matching or nonmatching partitions of the table. For more information
about processes and process boundaries, see “Operators Used for Parallelism or as Process
Boundaries” (page 18).
Nested Joins
In a nested join, a row from the outer table is used to probe the inner table for a match of one or
more rows. A buffer of rows is normally read from the outer table, and each row in turn is used
to probe the inner table. One message is sent to the inner table for each outer row.
The compiler chooses nested join when relatively few probes into the inner table are expected
and when the inner table is large.
In general, the estimated cardinalities for each operator will show the expected rows resulting
from the operation. With nested joins (and index-access joins and insert-select operations), the
24 Query Plan Operators