RE: RE: Index behavior

2003-11-06 Thread Larry Elkins
age- > From: [EMAIL PROTECTED] [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

RE: RE: Index behavior

2003-11-06 Thread Jared . Still
[EMAIL PROTECTED]>         cc:                 Subject:        RE: RE: Index behavior 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 h

RE: RE: Index behavior

2003-11-06 Thread Wolfgang Breitling
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 o

RE: RE: Index behavior

2003-11-06 Thread Henry Poras
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.

Re: Re: RE: Index behavior

2003-11-06 Thread Saminathan
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? Tha

Re: RE: Index behavior

2003-11-06 Thread Wolfgang Breitling
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

Re: RE: Index behavior

2003-11-05 Thread Saminathan
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 cl

RE: Index behavior

2003-11-05 Thread Goulet, Dick
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 li

Re: RE: Index behavior

2003-11-05 Thread Saminathan
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 rega

RE: Index behavior

2003-11-05 Thread Wolfgang Breitling
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 histogr

Re: Re: Index behavior

2003-11-05 Thread Saminathan
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,

Re: Index behavior

2003-11-05 Thread Daniel Fink
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

RE: Index behavior

2003-11-05 Thread Goulet, Dick
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 not