Re: cost
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 6 Apr 2004 09:37:55 +0100
Me, too.
I should have tested it before I emailed.
But I'm pretty sure there is an 8.1.7 version
where the result would not appear - although I
am only basing this claim on the memory of just
a few years ago where the optimizer calculated a
cardinality of 1, and joined to the next table
using a nested loop FTS. Unfortunately the actual
cardinality was not one, so the nested loop option
was much more resource intensive than the hash
join when it ran.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
April 2004 Iceland http://www.index.is/oracleday.php
June 2004 UK - Optimising Oracle Seminar
----- Original Message -----
From: "Wolfgang Breitling" <breitliw@xxxxxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Tuesday, April 06, 2004 1:48 AM
Subject: Re: cost
I get the same result (higher cost hash join chosen over NL join) with
Oracle 8.1.7.4.1
At 01:28 PM 4/5/2004, you wrote:
>My guess would be that this is a deliberate
>heuristic introduced some time around 9
>to avoid nested loop full tablescans when
>the numbers are small.
----------------------------------------------------------------
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:
