SQL/MX 2.x Query Guide (G06.24+, H06.03+)

Parallelism
HP NonStop SQL/MX Query Guide—523728-003
8-2
Pipelined Parallelism
Pipelined Parallelism
Pipelined parallelism is an inherent feature of SQL/MX because of its data flow
architecture. This architecture interconnects all operators by pipes, with the output of
one operator being piped as input to the next operator, and so on. The result is that
each operator works independently of any other operator, producing its output as soon
as its input is available. Pipelining is seen in almost all query plans. You cannot force
pipelined parallelism. It occurs as a natural by-product of the SQL/MX search engine.
Independent Parallelism
Independent execution is also an inherent feature of SQL/MX because of the
architecture. Independent parallelism means that two or more operators can execute
simultaneously. Except for certain synchronization conditions, the operators execute
independently; for example, the parts of a UNION query. Usually each of the
independent operators is connected by a pipeline to a common ancestor. Independent
parallelism could also be called operator parallelism, because it is the operators on the
data that execute in parallel. Independent parallelism occurs in many plans. Like
pipelining, you cannot force independent parallelism.
Parallel Execution Principles
Query Plan as a Data Flow Tree
The query plan is represented by a data flow tree with three types of nodes:
The next figure shows a basic query plan with the data flow elements identified.
Leaf nodes Each leaf node is a data source. Typically, the leaf node is either
a base table scan or an index scan.
Internal nodes Each internal node corresponds to an operator within the current
query. Like the operator itself, an internal node can be unary,
binary, or N-ary. The Exchange node is a special internal node
that represents a process boundary.
Root node Each plan has exactly one root node. The result of the query is
the output of the root node.