Radix index probe

 

A radix index probe operation is used to retrieve the rows from a table in a keyed sequence. The main difference between the Radix Index Probe and the Radix Index Scan is that the rows being returned must first be identified by a probe operation to subset the rows being retrieved.

The optimizer attempts to match the columns used for some or all of the selection against the leading keys of the index. It then rewrites the selection into a series of ranges that can be used to probe directly into the index's key values. Only those keys from the series of ranges are paged into main memory. The resulting row numbers generated by the probe operation can then be further processed by any remaining selection against the index keys or a Table Probe operation. This provides for very quick access to only the rows of the index that satisfy the selection.

While the main function of a radix index probe is to provide a form of quick selection against the index keys, the sequencing of the rows can still be used by the optimizer to satisfy other portions of the query (such as ordering or grouping). Since the I/Os associated with the index will only be for those index rows that match the selection, no extraneous processing will be performed on those rows that do not match the probe selection. This savings in I/Os against rows that are not a part of the result set for the query, is one of the primary advantages for this operation.

Table 1. Radix index probe attributes
Data access method Radix index probe
Description The index is quickly probed based upon the selection criteria that were rewritten into a series of ranges. Only those keys that satisfy the selection will be used to generate a table row number.
Advantages

  • Only those index entries that match any selection continue to be processed

  • Provides very quick access to the selected rows

  • Potential to extract all of the data from the index keys' values, thus eliminating the need for a Table Probe

  • Returns the rows back in a sequence based upon the keys of the index
Considerations Generally requires a Table Probe to be performed to extract any remaining columns required to satisfy the query. Can perform poorly when a large number of rows are selected because of the random I/O associated with the Table Probe.
Likely to be used

  • When asking for or expecting only a few rows to be returned from the index

  • When sequencing the rows is required the query (for example, ordering or grouping)

  • When the selection columns match the leading key columns of the index
Example SQL statement 
CREATE INDEX X1 ON Employee (LastName, WorkDept)

SELECT * FROM Employee WHERE WorkDept BETWEEN 'A01' AND 'E01'
AND LastName IN ('Smith', 'Jones', 'Peterson')
OPTIMIZE FOR ALL ROWS
Messages indicating use

  • Optimizer Debug: 
     CPI4328 -- Access path of file X1 was used by query.

  • PRTSQLINF: 
    SQL4008 -- Index X1 used for table 1. 
SQL4011 -- Index scan-key row positioning used            on table 1.
SMP parallel enabled Yes
Also referred to as Index Probe

Index Probe, Preload

Index Probe, Distinct

Index Probe Distinct, Preload

Index Probe, Key Positioning

Index Scan, Key Row Positioning

Visual Explain icon

Radix index probe icon

The following example illustrates a query where the optimizer might choose the radix index probe access method: 

     CREATE INDEX X1 ON Employee (LastName, WorkDept)
 
     SELECT * FROM Employee      WHERE WorkDept BETWEEN 'A01' AND 'E01'
     AND LastName IN ('Smith', 'Jones', 'Peterson')
     OPTIMIZE FOR ALL ROWS

In this example, the optimizer uses the index X1 to position (probe) to the first index entry that matches the selection built over both the LastName and WorkDept columns. The selection is rewritten into a series of ranges that match all of the leading key columns used from the index X1. The probe is then based upon the composite concatenated values for all of the leading keys. The pseudo-SQL for this rewritten SQL might look as follows: 

     SELECT * FROM X1
     WHERE X1.LeadingKeys BETWEEN 'JonesA01' AND 'JonesE01'
        OR X1.LeadingKeys BETWEEN 'PetersonA01' AND 'PetersonE01'
        OR X1.LeadingKeys BETWEEN 'SmithA01' AND 'SmithE01'

All of the key entries that satisfy the probe operation will then be used to generate a row number for the table associated with the index (for example, Employee). The row number will be used by a Table Probe operation to perform random I/O on the table to produce the results for the query. This processing continues until all of the rows that satisfy the index probe operation have been processed. Note that in this example, all of the index entries processed and rows retrieved met the index probe criteria. If additional selection were added that cannot be performed through an index probe operation (such as selection against columns which are not a part of the leading key columns of the index), the optimizer will perform an index scan operation within the range of probed values. This still allows for selection to be performed before the Table Probe operation.

 

Parent topic:

Radix index

 

Related concepts


Nested loop join implementation

 

Related reference


Effects of the ALWCPYDTA parameter on database performance