8.4.1 Runtime adaptive index processing The first runtime optimization enhancement is called  runtime adaptive index processing ,  which extends upon RID-based access paths (list prefetch and multi-index access) and adds  runtime enhancements to adapt at execution time based on index filtering. The simple SQL statement that is shown in Example 8-8 can be used to highlight the  challenge that generic (search) queries place on a query optimizer. Numerous coding is used  for this type of SQL. It is commonly used for search screens, where the user can complete  various fields and choose any or all combinations. Regardless of the technique that is used for the SQL, the premise is the same in that the  programmer wants to code a single SQL statement that can be generally used. Database  administrators fight this battle to have programmers construct dynamic SQL at execution time  that is specific to the input request, or to limit the combinations that are possible and code a  subset of targeted SQL. Typically, this battle is lost, and it becomes the responsibility of the  database to address the performance challenges.  Despite the option to bind the package with the REOPT(ALWAYS) bind option, this binding  might not be possible if the requests are coming into Db2 through DRDA because too many  SQLs use the same package, and similarly for static SQL, all SQL in the package are  affected. The SQL that is shown in Example 8-8 is used as a generic search query by enabling or  disabling each predicate that is based on the user input.  For example, if LASTNAME and CITY are entered, these predicates are populated with their  search values, as shown in the following example: LASTNAME LIKE 'SMITH' AND CITY LIKE 'SAN JOSE' All other predicates are populated with the following values: LIKE '%%%%%'  If the query was coded with BETWEENs for character columns, the following predicates are  used for numeric columns: BETWEEN 'AAAAAAAA' AND 'ZZZZZZZZ')  or  BETWEEN 0 AND 99999  The Db2 optimizer (or any optimizer) cannot choose one access plan that best matches the  filtering predicates because those predicates can change every execution. Chapter 8. Query performance  269 Example 8-8 Generic search SQL challenge SELECT *  FROM CUSTOMER WHERE LASTNAME LIKE ? AND FIRSTNAME LIKE ? AND ADDRESS LIKE ? AND CITY LIKE ?  AND ZIPCODE BETWEEN ? AND ?