The outer SELECT operates against the rows
and columns returned by the subquery, except
when the optimizer surprises you by doing
otherwise.
This is certainly not very satisfactory. At least, I 'm not
at all happy with it. Better might be:
The outer SELECT and subquery together describe the state of
the data to be returned by the statement, but to get that
state the database will perform various operations in some
indeterminate order.
This I like better, but still leaves me vaguely unsatisfied.
For one thing, the "state of the data " cannot be properly
understood without also visualizing the results from the
subquery, so I 'm left with a bit of a chicken/egg problem.
It 'll probably take me awhile to come up with a mental model
that I like.
In the end though, I 'm not trying to coerce a given
execution plan, but rather I 'm trying to reconcile my mental
model for subquery execution with this behavior that we 're
seeing.
Best regards,
Jonathan Gennick --- Brighten the corner where you are
http://Gennick.com * 906.387.1698 * mailto:jonathan@(protected)
Join the Oracle-article list and receive one
article on Oracle technologies per month by
email. To join, visit http://five.pairlist.net/mailman/listinfo/oracle-article,
or send email to Oracle-article-request@(protected) and
include the word "subscribe " in either the subject or body.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe send email to: oracle-l-request@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
