Home | Previous Page | Next Page   Monitoring Database Server Performance > Monitoring Sessions and Queries >

The Iterator Model of Extended Parallel Server and the Structure of Xplans

Query plans in Extended Parallel Server are based on the iterator model that was introduced by the Volcano research project at the University of Colorado in the late 1980s. An iterator is a common interface for database operations such as scans, joins, and groups. An iterator can usually have up to two inputs and one or more outputs. All iterators offer the functions create, open, next, and close. Which function a specific iterator instance is currently executing can be deduced from the state of the iterator.

Table 4 shows iterator states. See Table 5 for more information about hash join states.

Table 4. Iterator States
Iterator State Explanation
Create This is the initial state of an iterator instance, after the instance has been created.
Open This is the state of the iterator instance, after the instance has been opened by its parent.
Next This is the state when rows are fetched by the parent of the iterator.
Done The last fetch reached the end of the data.
Close The iterator instance is closed.

Table 5. Special Hash Join States
Iterator State Explanation
Build The hash join is building the hash table with the first (usually the smaller) join table.
Probe The hash join is now probing with the second table against the in-memory hash table.
Overflow The hash join iterator had overflow and the iterator is now processing the overflow.

An iterator corresponds to a single operation of the implementation of the relational algebra. Queries are represented by an iterator tree, which actually is an iterator directed acyclic graph (DAG). The iterator tree connects the output of one iterator i0 with the input of another iterator i1. i1 is called the parent of i0.

The figure below shows an example of an iterator tree. In this example, two scan iterators are below a hash join iterator and above the hash join iterator are two group iterators. This iterator tree is typical for a query that is joining two tables and performing some aggregation afterwards.

Figure 11. Example of an Iterator Tree

Before the server can execute a query, the server must determine the following:

This means the degree for horizontal and pipelining parallelism must be determined. The execution model for the parallel execution of an iterator tree in Extended Parallel Server is the xplan.

Extended Parallel Server introduces four xplan elements:

The branches/iterators in one segment exchange data via shared memory. The communication between segments is via message passing. The exchanges connect the output links of an iterator at the top of one segment to the input links of another iterator at the bottom of another segment. This means segments are the unit for memory allocation and for determining the degree of pipelining parallelism for iterators which are not "stop-and-go" iterators.

onstat Commands to Use for Displaying Information

Use the onstat -g rqm command to determine which queries with xplans are active.

Use the onstat -g xit command to display the iterator tree for a query.

Use the onstat -g xqp command to display the query plan for a query.

Use the onstat -g xmp command to display information about the currently executing iterators of the query while the query is executing.

Use the onstat -g xqs command to display information about iterators that have already completed their execution.

For more information on the onstat commands cited above, see the IBM Informix: Extended Parallel Server Administrator's Reference.

Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]