|
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #619427 is a reply to message #619425] |
Tue, 22 July 2014 07:30 |
Solomon Yakobson
Messages: 3273 Registered: January 2010 Location: Connecticut, USA
|
Senior Member |
|
|
Be careful! I don't know if it is a bug but short circuit and analytic functions not always play well together:
with t as (
select 1 id,-1 val from dual union all
select 2,2 from dual union all
select 3,-3 from dual union all
select 4,0 from dual
)
select id,
val,
case val
when 0 then 0
else
ln(abs(val))
end x
from t
order by id
/
ID VAL X
---------- ---------- ----------
1 -1 0
2 2 .693147181
3 -3 1.09861229
4 0 0
SQL>
And with analytic functions:
with t as (
select 1 id,-1 val from dual union all
select 2,2 from dual union all
select 3,-3 from dual union all
select 4,0 from dual
)
select id,
val,
case val
when 0 then 0
else
sum(ln(abs(val))) over(order by id)
end x
from t
order by id
/
ERROR:
ORA-01428: argument '0' is out of range
no rows selected
SQL>
SY.
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #619768 is a reply to message #619427] |
Fri, 25 July 2014 00:10 |
|
Kevin Meade
Messages: 2103 Registered: December 1999 Location: Connecticut USA
|
Senior Member |
|
|
short circuit (assuming your use is the same as mine), is an optimization feature. That means, it is not part of any mandatory syntax or process. There is no requirement that short circuiting must happen either in pl/sql or sql execution. More importantly perhapes, Oracle is free to change its database at any time and without notice to make more or less or different use of short circuiting if they believe it will create a better product.
With that in mind you should not be relying on short circuiting for any reason.
However, as a topic for discussion which is why I am thinking you have asked your questions, Oracle SQL does do short circuiting when it optimizes its queries. The order of predicate evaluation is managed by many rules and these change with every release. For example, Oracle 11gR2 introduced "costed predicate evaluation" such that Oracle will automatically evaluate predicates in whatever order it feels is best, based on a statistical costing of the predicates. This of course means the short circuiting behavior has changed in 11g from previous releases and observed behavior in the past may not be duplicated.
Similarly, there was a big push in 11g to introduce many PL/SQL optimizations that are automatic. As a result, the performance profile of PL/SQL code can change considerably just by moving from a 10g or 9i version to 11gR2. Once again, several of these optimization involve code rewrites and thus potential change to the behavior of short circuiting in PL/SQL decision trees.
In the end it is a neat feature that you can't really control too much other than to turn it off. You are pretty much at the mercy of the database for it both in PL/SQL and SQL, you can't really see it without doing lots of testing, and it will change over time.
Hope this is the kind of info you were looking for. Kevin
Kevin
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #619822 is a reply to message #619768] |
Fri, 25 July 2014 04:56 |
Solomon Yakobson
Messages: 3273 Registered: January 2010 Location: Connecticut, USA
|
Senior Member |
|
|
Kevin Meade wrote on Fri, 25 July 2014 01:10short circuit (assuming your use is the same as mine), is an optimization feature. That means, it is not part of any mandatory syntax or process. There is no requirement that short circuiting must happen either in pl/sql or sql execution. More importantly perhapes, Oracle is free to change its database at any time and without notice to make more or less or different use of short circuiting if they believe it will create a better product.
Kevin,
Oracle use of short-circuit is documented and is explained, so it is "mandatory" when using features for which Oracle explicitly states it is using short-circuit. Just few examples:
1. COALESCE:
Oracle Database uses short-circuit evaluation. The database evaluates each expr value and determines whether it is NULL, rather than evaluating all of the expr values before determining whether any of them is NULL.
2. Short-Circuit Evaluation
When evaluating a logical expression, PL/SQL uses short-circuit evaluation. That is, PL/SQL stops evaluating the expression as soon as it can determine the result. Therefore, you can write expressions that might otherwise cause errors.
3. DECODE
Oracle Database uses short-circuit evaluation. The database evaluates each search value only before comparing it to expr, rather than evaluating all search values before comparing any of them with expr. Consequently, Oracle never evaluates a search if a previous search is equal to expr.
4. CASE
Oracle Database uses short-circuit evaluation. For a simple CASE expression, the database evaluates each comparison_expr value only before comparing it to expr, rather than evaluating all comparison_expr values before comparing any of them with expr. Consequently, Oracle never evaluates a comparison_expr if a previous comparison_expr is equal to expr. For a searched CASE expression, the database evaluates each condition to determine whether it is true, and never evaluates a condition if the previous condition was true.
SY.
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #619824 is a reply to message #619424] |
Fri, 25 July 2014 05:14 |
John Watson
Messages: 8929 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
saipradyumn wrote on Tue, 22 July 2014 12:36Hi Lalit ,
I did the basic searching before posting.
But from the below link I got the information that Oracle does not guarantee that a SQL statement
will use short-circuit evaluation (though PL/SQL is guaranteed to perform short-circuit evaluation)
http://stackoverflow.com/questions/8900631/does-oracle-use-short-circuit-evaluation
I just wants to confirm with the forum
Thanks
SaiPradyumn In this example, Oracle is using short-circuiting in SQL and evaluating the predicates in the order given:orclz>
orclz> select * from scott.dept where deptno/deptno=1 or deptno/0=1;
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
orclz> select * from scott.dept where deptno/0=1 or deptno/deptno=1;
select * from scott.dept where deptno/0=1 or deptno/deptno=1
*
ERROR at line 1:
ORA-01476: divisor is equal to zero
orclz> select * from v$version;
BANNER CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0
PL/SQL Release 12.1.0.1.0 - Production 0
CORE 12.1.0.1.0 Production 0
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production 0
NLSRTL Version 12.1.0.1.0 - Production 0
orclz>
|
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #620001 is a reply to message #619838] |
Sun, 27 July 2014 08:18 |
Solomon Yakobson
Messages: 3273 Registered: January 2010 Location: Connecticut, USA
|
Senior Member |
|
|
Kevin Meade wrote on Fri, 25 July 2014 09:24I guess this is one of those "differences of professional opinion".
I can post hundreds of examples where short-circuit logic is applied but it will not mean a thing since you can always say there might be a case when it isn't applied. However when Oracle explicitly and if full detail tells how short-circuit works and what operations use short-circuit, our opinions doesn't matter. We get what Oracle gives us. But bright side is - we can always open SR when it doesn't work as listed. So if you have a case when short-circuit is not working as advertised please post it here so we are aware. I posted one with analytic functions. I ran into this long time ago but never reported it to Oracle. Now, after this discussion, I will open SR with Oracle.
SY.
|
|
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #620021 is a reply to message #620012] |
Sun, 27 July 2014 22:56 |
|
Kevin Meade
Messages: 2103 Registered: December 1999 Location: Connecticut USA
|
Senior Member |
|
|
SELECT CASE y
WHEN 0 THEN 0
ELSE x / y
END
FROM TBL
That will be fine. But something more along these lines. Works good in 9i and 10g, breaks in 11g. Developers relied on predicate evaluation rules (of which short circuiting is a part) to ensure that c1 > 0 happened before funcx(c1) = 1. Then 11g went all automatic cost based predicate ordering and reversed it on them because it deciced the function based predicate was more selective than the column one (default stats and all that). This is of course a developer error because they should have allowed for 0 as an input parameter and dealt with it. But it showed up because Oracle decided to enhance the effectiveness of predicate short circuiting through and automatic statistics based predicate reordering.
select *
from tbl
where c1 > 0
and funcx(c1) = 1
/
funcx (p1 in number) return number is
begin
return (1/p1);
end;
/
There are many forms of short circuiting. Your example of CASE shows that CASE executes logic in a specific order and quits when it has found a match. It must do that or it does not perform its function of CASE. But other forms of short circiuting or more "flexible". When short circuiting is an optimization technique rather than a definition of form, it is a mistake to rely on it.
We are both right. Just having at it from the two opposite ends. Nothing wrong with that.
Kevin
[Updated on: Sun, 27 July 2014 23:01] Report message to a moderator
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #620080 is a reply to message #620021] |
Mon, 28 July 2014 11:31 |
Solomon Yakobson
Messages: 3273 Registered: January 2010 Location: Connecticut, USA
|
Senior Member |
|
|
Kevin Meade wrote on Sun, 27 July 2014 23:56Developers relied on predicate evaluation rules (of which short circuiting is a part) to ensure that c1 > 0 happened before funcx(c1) = 1.
Kevin,
Developers confused short-circuit and precedence. Short-circuit stops evaluating the expression as soon as it can determine the result. But it is condition/operator precedence which determins evaluation order. Developers didn't take precedence into account:
SQL Language Reference manualPrecedence is the order in which Oracle Database evaluates different conditions in the same expression. When evaluating an expression containing multiple conditions, Oracle evaluates conditions with higher precedence before evaluating those with lower precedence. Oracle evaluates conditions with equal precedence from left to right within an expression, with the following exceptions:
•Left to right evaluation is not guaranteed for multiple conditions connected using AND
•Left to right evaluation is not guaranteed for multiple conditions connected using OR
So all your example shows is incorrect assumptions will backfire sooner or later.
SY.
[Updated on: Mon, 28 July 2014 11:57] Report message to a moderator
|
|
|
|
Re: Short-Circuit Evaluation operators in oracle [message #620091 is a reply to message #620084] |
Mon, 28 July 2014 12:59 |
Solomon Yakobson
Messages: 3273 Registered: January 2010 Location: Connecticut, USA
|
Senior Member |
|
|
Kevin,
OK. In my definition short-circuit was also guaranteeing order of evaluation. Oracle definition is more granular: "short-circuit stops evaluating the expression as soon as it can determine the result" and precedence defines order in which conditions are evaluated. That's where I was wrong. So using Oracle' definitions short-circuit and precedence are used when evaluating WHERE clause. But it doesn't change much. Developers still made wrong assumption. They forgot about the precedence and assumed Oracle will always do left-to-right evaluation of AND connected conditions. Yes Oracle will stop evaluation WHERE clause as soon as it can determine the result but it clearly states one can't assume the order in which AND or OR connected predicates are executed. And that's what I highlighted in my reply. So WHERE clause:
where c1 > 0
and funcx(c1) = 1
is evaluated as follows. There are two conditions connected using AND, therefore we can't assume which condition Oracle will evaluate first. But we are guaranteed that if condition Oracle decides to evaluate first determines the result other condition will not be evaluated - that's the extent of short-circuit we are getting in WHERE clause.
SY.
|
|
|