Stephane,
Three things I don't need to tell you about
your example:
Prior to CPU-costing in 9, the order of
single table predicates can have a dramatic
impact on CPU without changing the amount
of logical I/O.
Logical I/O should always include the statistics
"buffer is pinned count" - it's just
Thanks Stephane (1000 pardons on the earlier spelling FO-PAH!).
-Original Message-
Faroult
Sent: Wednesday, April 02, 2003 2:29 PM
To: Multiple recipients of list ORACLE-L
Karen Morton wrote:
>
> Stephanie,
Cough, cough.
> I've ran into the exact same thing that statistics don't alway
Karen Morton wrote:
>
> Stephanie,
Cough, cough.
> I've ran into the exact same thing that statistics don't always tell the
> real story and that the bottom-line has to be elapsed time.
>
> I am curious however as to how you wrote the best performing (fastest)
> query. I have a client who uses
Once upon a time, I had a developer come to my desk complaining that their
query ran very poorly that day, Monday, and that it ran fine on Friday. And
since we had a snapshot of the DB as of that Friday, the dev showed me. The
dev also said that the only change was that WE changed the statistics
Stephanie,
I've ran into the exact same thing that statistics don't always tell the
real story and that the bottom-line has to be elapsed time.
I am curious however as to how you wrote the best performing (fastest)
query. I have a client who uses the exact same structure and methodology
you ment
Had to forward this to the "God of Obfuscated SQL" here. He in the past created a
"select * from bom_with_assembly_steps" query in a Forms3 application that could take
as long as an hour to complete. Something on similar lines to what you have. Thank
GOD for Explain SQL/Platinum Plan Analyzer
Congratulations Stephane -- a good lesson for us all.
Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Tuesday, April 01, 2003 3:14 PM
To: Multiple recipients of list ORACLE-L
The case is not as bad as the subject may let you believe, bu
> -Original Message-
> From: Stephane Faroult
>
>
> A moral to the story? SET TIMING ON. What matters is elapsed time, not
> stats. That said, I must check events next week.
>
Another lesson, which probably wouldn't make any difference in your
case, is to run tests more than once, s
