The NRDB optimized read process performs the following general steps:
PowerExchange parses the SQL WHERE clause into components that the read process and post-read qualification process can use.
The candidate key process determines the conditions in the WHERE clause that the optimized read process can use.
The optimized read process determines the actual values for those conditions that meet its criteria. The result is a set of low- and high-value pairs for each column.
The read process rationalizes the low- and high-value pairs for multiple columns into a single set of low- and high-value pairs.
The read process retrieves legacy data records with key values between the low- and high-value pairs and maps the data records to columns.
The qualification rules for the read process indicate which rows are to be selected.
PowerExchange sends the selected rows to the calling application.
NRDB optimized read processing performs the first three steps once during initialization. The process performs steps 4 and 5 once during initialization or when new parameter values are supplied during a lookup. The process performs steps 6 through 9 once for each row.
When exact low and high value pairs cannot be determined, legacy rows are returned from the interface modules and subsequently deselected by the qualification rules.
In addition, the optimized read process cannot use filter-after-offloading because that option requires processing the entire data set on Linux, Unix, or Windows. The optimized read process can use filter-before-offloading, but performance gains are minimal when compared to non-offloaded processing if there are few records in the result set.