Comments on: Conditional SQL (2)

By: VSharma

VSharma — Tue, 25 Mar 2008 12:27:46 +0000

Hi Jonathan,

Based on the example provided by you, I do not see the difference, in terms of logical i/o’s, between the query with NVL and without NVL i.e.
n1=nvl(:b1,n1) the I/O is 14 Gets and with
n1=:b1, the I/O again is 14 Gets. Infact, when I changed the query to incorporate the changes suggested Paul James, i.e. (n1=:b1 or :b1 is null), the optimizer opted only for a Full Table Scan of T1 and the I/O’s were way high (364 I/O’s).

Hence, to me it seems the original plan of Split and Concatenation is a good choice.

What is your say on this ?

Regards

By: Jonathan Lewis

Jonathan Lewis — Thu, 15 Feb 2007 15:39:41 +0000

Paul, a quick test on a single table (9.2.0.8 and 10.2.0.1) suggests that this optimisation is a very special case aimed very precisely at the nvl(:b1,colX) and equivalant decode() statemetns. The equivalent statement using your suggested approach results in a simple tablescan access path, and no concatenation – even when I added the USE_CONCAT hint.

By: Paul James

Paul James — Thu, 15 Feb 2007 10:17:40 +0000

Johnathan,

Thanks for the answer. I’ve also seen…

AND ( n1 = :b1
OR :b1 IS NULL)

Would this be any better than the original code?

By: Jonathan Lewis

Jonathan Lewis — Wed, 14 Feb 2007 16:46:03 +0000

Anonymous, certainly a point worth raising. There are always compromises that have to be made, especially in high-concurrency systems: the skill lies in getting the cost/benefit balanced properly.

The “bind variables are good for OLTP” argument often gets a little over-used, or abused, in cases where the argument for “a few” specialised cursors has some merit.

By: Anonymous

Anonymous — Wed, 14 Feb 2007 16:14:30 +0000

One reason people I work with give for doing this, is because then “you only use one cursor instead of two, and that way you benefit from [cursor] caching”.

I doubt that any caching benefit would outweigh the inefficient execution plans this could give you, but I wanted to throw it out there.

By: Jonathan Lewis

Jonathan Lewis — Wed, 14 Feb 2007 14:42:28 +0000

Tobias, better yet is this example from http://tkyte.blogspot.com/2006/10/slow-by-slow.html which reads: My mantra, that I'll be sticking with thank you very much, is: You should do it in a single SQL statement if at all possible. If you cannot do it in a single SQL Statement, then do it in PL/SQL. If you cannot do it in PL/SQL, try a Java Stored Procedure. If you cannot do it in Java, do it in a C external procedure. If you cannot do it in a C external routine, you might want to seriously think about why it is you need to do it… But I don't think Tom is suggesting you could write the entire application with a single SQL statement. Your reference, and my quote, relate to items comparing set-wise processing and row-by-row processing. I doubt if Tom would have any worries about having a little procedural control over which set-wise operation to use. Of course, there are some people who go a bit over the top with the "one SQL statement" approach - but I don't think that is the common cause for this particular error: it's more likely to be code-generators, and programmers whose only concern is meeting the specification of content with no regard for performance. If you really want to stick to the single statement, then you could simply concatenate (union all)the various bits of SQL, remembering to include the relevant is null and is not null predicates to get complete non-overlapping coverage. But that's not so easy as nulls are counter-intuitive. The name, by the way, is Jonathan, not John.

By: Tobias

Tobias — Wed, 14 Feb 2007 14:03:19 +0000

Hi John,

Tom Kyte keeps saying:

“Never do procedurally that which can be done in a single sql statement”

For example on this posting:

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6407993912330

or in many of his presentations.

I believe that is the reason why many people try to write 1 sql statement to return the data they need.

Thanks

By: Jonathan Lewis

Jonathan Lewis — Wed, 14 Feb 2007 11:58:21 +0000

Paul, as a general principle, code the calling program with something like:
if (variable is null) then execute SQL-statement-1 else execute SQL-statement-2 end if;
If this is going to give you too many options (2^N for N variables) then restrict the set of statements to those that make the efficient access paths possible and put up with the the fact that some of the filter predicates will still have to use the nvl() construct.

By: Paul James

Paul James — Wed, 14 Feb 2007 10:00:30 +0000

So, how would you “fix the code” then.

I’m asking because this approach is still taken where I work to allow parameters to be passed in as NULL.