Keep in mind that this is just one test case – you may find that if you change the order of the UPDATE statements so that the test statement with the IS NOT NULL predicate specified in the WHERE clause is executed first, that it then becomes the most efficient method (it could be that the previous rolled back UPDATEs changed the high watermark of the tables). It could be that if I ran the first set of tests on the other server (the one that performed 212,520,861 consistent or current mode gets in 4,853.41, rather than the one that only performed 114,905,284 consistent or current mode gets in 9,763.26 seconds) that the results would be about even or in favor of the IS NOT NULL constraints. It could be that if I had not changed the STATISTICS_LEVEL from TYPICAL to ALL that the elapsed time might have been identical. What is great about well constructed test cases is that anyone can take the test case, run it on their system, make small modifications to the test case, and see how the performance changes.

Keep in mind that this test case only looked at the NOT IN type of subquery for an UPDATE statement (not that in one case the optimizer changed it to NOT EXISTS). The results could be completely different for DELETE or SELECT statements. As Greg Rahn confirmed, the potential for NULL values limits the options of the cost-based optimizer to find more efficient execution plans (and that can impact the performance). You might ask, what if one (or both) of the columns were indexed – how much that impact the test, since by default NULL values are not included in single column B*Tree indexes (and there is the potential for NULLs)? With the above test case, you could make a couple modifications, maybe add a more restrictive WHERE clause, to see how the potential for NULL values affects the optimizer.

Then, of course, there is always the risk that someone will set OPTIMIZER_FEATURES_ENABLE to a value less than 11.1.0.6, and suddenly, rather than executing in 4 minutes, it maxes out one of the CPUs for 3+ hours, and is not event 10% finished when the query is forced to be killed.

I would suggest that if a column should never include NULL values, that it should have a constraint that prevents NULL values from being added in the column. Doing so will help the query optimizer, and reduce the need to add seemingly unneeded IS NOT NULL predicates to the WHERE clause.

Anyone else have an opinion?

Nice one. Thanks.
But I am actually bit confused with the results in 11.1.0.7.
Why were the number of consistent gets more when we did “right” thing (i.e. either to use IS NOT NULL predicate or define a NOT NULL constraint) than those when we did not bother to do the “right” thing (i.e. no NOT NULL constraint or IS NOT NULL condition) ? Does this mean from 11g onwards, it is better to not use NOT NULL constraint or IS NOT NULL predicate ?

My last comment in the post suggested that the problem might be that even though there might not be any NULL values in the columns, the column definitions might permit NULL values, and that alone might restrict the options that are available to the optimizer for re-writing the SQL statement into a more efficient form.

This is true. If columns can be determined to be NOT NULL there are more query transformations that can take place. When using NOT IN() it leaves NULL to be a possibility unless the column is NOT NULL or a AND NOT NULL predicate is used. Execution times will generally be worse if the NOT NULL predicate can not be applied (implicitly or explicitly) and no NULL values exist. I’ve seen this countless times.