It is a common misunderstanding of the EXISTS clause that the subquery will terminate as soon as it finds the existence of a row; that it doesn’t matter whether one row or one million rows match.
This is only true if the subquery is correlated . If it is not, its performance can actually be marginally worse than the SELECT COUNT(*), because it incurs the cost of accessing sysibm.sysdummy1 besides accessing all the rows matching the WHERE clause.
The column IBMREQD is the only column of the SYSDUMMY1 table. By coding this in an “always true” predicate in the subquery, the subquery will not be executed until the first row of SYSDUMMY1 is retrieved.
Now the EXISTS clause will execute exactly how we expected. SYSDUMMY1 has only 1 row, which will be retrieved, and the correlated subquery will then be executed. With the EXISTS clause, as soon as one match is found, the search will terminate and return TRUE to the outer query.
The authors of my source article say, “For existence checking in V6 and earlier, the technique of coding a cursor with OPTIMIZE FOR ONE ROW, opening the cursor, and simply fetching one row, has generally proven to be the existence checking method that provides the best performance.”
Coding a cursor with the clause OPTIMIZE FOR ONE ROW tells DB2 that you only intend to fetch the first row, regardless of how many rows are returned.
The optimizer may disable such optimization features as List and Sequential Prefetch, depending on whether the access path can benefit from it.
Without this clause, the optimizer determines the most efficient access path for the full result set, and this usually is not the most path for accessing just one row.
OPTIMIZE is not valid syntax for singleton selects, and is also not effective for SQL coded within products such as QMF, SPUFI and PRF. However, it works well for dynamic or static cursors embedded within an application program since you have the capability to control the number of rows that are fetched.
The sample program and its output at the end of the slides shows that, in fact, the optimized cursor, and even the non-optimized cursor proved faster than the WHERE EXISTS clause in our student absence example.
The FETCH FIRST (1) ROW ONLY clause, implemented in DB2 V7, limits the number of rows returned by the query to one, regardless of how many rows qualify from the WHERE clause.
It also implies OPTIMIZE FOR 1 ROW.
It can be coded in a singleton select, informing the optimizer to determine the best access path for the retrieval of one row and not to perform the internal 2 nd fetch that SQL usually does to determine whether to return a –811.
“ Due to the ability to limit the result set to one row, and also inform the optimizer of this intention, this technique should become the new standard for existence checking from V7 onwards.”