I'm referring more to the fact that on subsequent runs of the origional
code and altered code, some blocks are going to be cached in the buffer
cache. I'm not referring to parsing. The env is RBO, so there is no cost
number to compare and we have even previously discussed that even in CBO
mode, cost is not always indicator of past plan. CBO or RBO does'nt
matter in this thread other than mentioning there is no costing number to
cmpare. When steps in an execution path are very similiar, I usually
defer to tkproff output to reflect the best resulting query. However,
when the data is either all or mostly in memory, then comparing results
from the baseline of first run time and pulling from disk...things get a
bit muddy.
- David
> its compiling the sql the first time. So check it the second time. when
> oracle compiles sql it hits the data dictionary several times. so your
> data is higher.
>
> now if you are not using bind variables, then you are recompiling every
> time...
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
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
-----------------------------------------------------------------
Received on Mon May 03 2004 - 11:00:31 CDT
