RE: to_number question
- From: "Poras, Henry R." <Henry_Poras@xxxxxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 16 Jul 2004 11:05:24 -0400
But wait, now we are getting into other problems. The object of the optimizer is
to determine the optimal physical access path to the data, in order to return
our desired result set. There are always numerous ways to ask the same query.
There are different SQL syntaxes which will always return identical result sets.
An ideal optimizer will be aware of these identities and always use the same,
optimal, execution plan regardless of how we phrased the query. Performance
shouldn't be dependent on how we write the queries. It has been in the past as
optimizers aren't perfect, but the goal is to move away from this. If we can
decide that the optimizer needs to be aware of the parenthesis, we are now
saying that we want our syntax to influence the execution plan and hence
performance. Ugh!!
Henry
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Stephen.Lee@xxxxxxxx
Sent: Friday, July 16, 2004 10:39 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: to_number question
I think at the heart of the argument that the error should not occur (at
least MY opinion) is that we CAN impose an order on processing so that (A or
B) and C is not the same as A or (B and C), and the RDBMS is not allowed to
throw away the parenthesis and do the processing in any way it chooses.
So at least some folk around here don't like the fact that it is OK for the
RDBMS to "throw away the parenthesis" in the case of a subquery when an
optimizer that is too smart for its britches can form a logically equivalent
query ... assuming no errors occur.
Maybe it's a purely pragmatic thing based on what gives the best performance
most of the time. Whatever the reason, I haven't been convinced that it has
any basis in relational theory. It seems to be nothing more than a
specification.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
