Actually, it has nothing to do with any of the table or index statistics.
OK, almost nothing. I suppose if Jonathan (Lewis) can get the optimizer to
do a FTS on an umpteen billion row table to retrieve a single row by its
prime key, one can concoct a scenario of statistics values, aided by init
Hi Wolfgang
Thanks for your valuable information. But still I could not understand how the
cardinality will be calculated in EXPLAIN PLAN?
In my query
(1)AB% returns (220 rows selected) but (card=2)
(2)ABC% returns (207 rows selected) but (card=12607 )
Could someone please explain to me?
OK, I can follow that, but why the change between ABC% and AB% ?
Henry
-Original Message-
Wolfgang Breitling
Sent: Thursday, November 06, 2003 10:19 AM
To: Multiple recipients of list ORACLE-L
Actually, it has nothing to do with any of the table or index statistics.
OK, almost nothing.
I don't know. I'm just reporting what I found. It was new to me too.
At 09:39 AM 11/6/2003, you wrote:
OK, I can follow that, but why the change between ABC% and AB% ?
Henry
Wolfgang Breitling
Oracle7, 8, 8i, 9i OCP DBA
Centrex Consulting Corporation
http://www.centrexcc.com
--
Please see the
spreadsheet. At least, that's what I would do
to try and understand it .
Jared
Henry Poras [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/06/2003 08:39 AM
Please respond to ORACLE-L
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: RE: Index
] [mailto:[EMAIL PROTECTED] Behalf Of
Wolfgang Breitling
Sent: Thursday, November 06, 2003 9:19 AM
To: Multiple recipients of list ORACLE-L
Subject: Re: RE: Index behavior
Actually, it has nothing to do with any of the table or index statistics.
OK, almost nothing. I suppose if Jonathan
Sami,
Your problem is not with the index, but rather the cost based optimizer. Most
of us have been beat severely over the head and shoulders through the years that full
table scans are a BAD thing, me included BTW. Well, it's time for the old dog to
learn new tricks. So that I'm
Jeff's paper (and other relevant ones) can be found on Tim Gorman's site
(www.evdbt.com).
Daniel Fink
Goulet, Dick wrote:
Sami,
Your problem is not with the index, but rather the cost based optimizer.
Most of us have been beat severely over the head and shoulders through the
Daniel,
Thank you so much.
-Sami
-Original Message-
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Date: Wed, 05 Nov 2003 12:19:25 -0800
Jeff's paper (and other relevant ones) can be found on Tim Gorman's site
(www.evdbt.com).
Daniel Fink
Goulet, Dick wrote:
Sami,
But that doesn't really explain why the optimizer chooses an FTS with a
predicate that presumable is more selective (name like 'ABC%') and an index
scan with a predicate that presumable is less selective (name like 'AB%').
I could understand it if it were the other way around.
Is there a
I went thru the document provided by Daniel and also
Metalink DocID NOTE.67522.1
But my scenario is totally different from what they have explained.
I didn't expect oracle to USe index all the time but why it is using INDEX scan for
'AB%' and NOT 'ABC%'.
Thanks everyone. Any help on this
Can I ask for the following:
1) The clustering factor on the index
2) number of distinct keys
3) number of leaf blocks
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-Original Message-
Sent: Wednesday, November 05, 2003 4:05 PM
To: Multiple recipients of
Hi Goulet,
The clustering factor on the index=37930
number of distinct keys=38357
number of leaf blocks=1075
Thanks
Sami
-Original Message-
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Date: Wed, 05 Nov 2003 13:49:28 -0800
Can I ask for the following:
1) The
13 matches
Mail list logo
