Why is it useful?
In DB2 10.5, there is a option DB2_INLIST_TO_NLJN *********************
•Operating system: All •Default=NO, Values: YES or NO
•In some situations, the SQL and XQuery compiler can rewrite an IN list predicate to a join. For example, the following query: SELECT * FROM EMPLOYEE WHERE DEPTNO IN ('D11', 'D21', 'E21') could be written as: SELECT * FROM EMPLOYEE, (VALUES 'D11', 'D21', 'E21) AS V(DNO) WHERE DEPTNO = V.DNO
This revision might provide better performance if there is an index on DEPTNO. The list of values would be accessed first and joined to EMPLOYEE with a nested loop join using the index to apply the join predicate. Sometimes the optimizer does not have accurate information to determine the best join method for the rewritten version of the query. This can occur if the IN list contains parameter markers or host variables which prevent the optimizer from using catalog statistics to determine the selectivity. This registry variable causes the optimizer to favor nested loop joins to join the list of values, using the table that contributes the IN list as the inner table in the join. *********************
We want the same option in Informix to have better performance used by IBM Cognos to generate native SQL send to Informix.
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "email@example.com" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions