Comments on: Conditional SQL – 3

By: Jonathan Lewis

Jonathan Lewis — Thu, 04 Nov 2010 07:48:50 +0000

Zahir,
I think Narenda has probably answered your question. A minor detail, though: the concatenation path is no available for “:bind is null or col = :bind”, it’s only available for the nvl() and a specific case of decode().

Technically, then, it’s possible that the code I supplied could have been modified to use the nvl() mechanism rather than being rewritten with the UNION ALL mechanism – but it’s not always appropriate thanks to the issues of NULLs that I have pointed out elsewhere.

By: Narendra

Narendra — Mon, 01 Nov 2010 04:21:48 +0000

Zahir,

I am sure Jonathan will explain it much better but let me see what I can do :)
I think what Tom has mentioned in his reply is that 8i was the last version where oracle ALWAYS generated a plan containing a single access path (full table scan) for these type of queries. Starting from 9i onwards, oracle is capable to generate a plan that can have two access paths and either of those will be chosen at run time. If you read Jonathan’s post (linked above), it explains this in detail (and also tells that the plan swiches back to full table scan when you have more than one sunch predicates in WHERE clause.)

p.s. Apologies Jonathan for jumping in your question.

By: Zahir Mohideen

Zahir Mohideen — Mon, 01 Nov 2010 01:16:43 +0000

Hello Jonathan ,

It was mentioned in Oracle 8i manual ( the concept of predicate collapsing) .
I was of the same thinking as yours about the above statement .

And I asked the follow up question to the similar posting in ask tom site
( http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2689943800346359019#2691231100346040851).

Per Tom , this is no longer the case . Please advise , if I misunderstood the concept or nvl expansion .

Cheers.