I think the interesting thing is, why did it look at
an index not in select/where/sort operations at
all?Best idea I have heard so far is that somehow it
thinks that gathering the rowids from the index and
doing a table lookup is better than a fts. LElking
floated the idea that it might have to do with a high
HWM and a low number of of rows, perhaps combined with
an index on a not-null col. Even Oracle was reluctant
to admit that it was accessing a wacko index until I
pressed them for it. I asked them to give me the
relevant CBO code, but noooooo, not even a decent
10053 doc.....



--- Jonathan Lewis <[EMAIL PROTECTED]>
wrote:
> 
> I believe that Waleed's response is essentially
> correct.
> The numbers still don't make sense, but ...
> 
> a) 250,000 blocks with the mbrc = 64.  The t/s cost
>     (according to my observations on 9.0.1 and
>      8.1.7) should be based on an adjusted mbrc
>     of 15.5
> 
>         250,000 / 15.5 = 16,000
> 
> b)    Using an index to hit every block, Oracle is
>     able to determine from data clustering stats
>     that many consecutive index leaf values will
>     hit a single data block, therefore can estimate
>     the single read-count via index as 250,000 -
>     but you have told it to reduce this by a factor
>     of 1/100 - for a total of 2,500.
> 
> Unfortunately for the theory, both your costs
> are 4,924 - so the T/S cost is close to the
> traditional "table blocks / simple mbrc", and
> index cost is too high be a factor of 2, which
> may be due to some internal bitmap index
> clustering fudge factor - some of the critical
> bitmap index numbers apparently used to be
> hard-coded constants.  Possibly it just means
> that your bitmap column has two values (and
> of course I haven't allowed a count for the
> number of leaf blocks in the index !).
> 
> 
> Details notwithstanding - I suspect that
> calculations
> like the above are the reason why Oracle decided
> that a full indexed path was cheaper than a scan.
> 
> 
> 
> 
> 
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
> 
> Author of:
> Practical Oracle 8i: Building Efficient Databases
> 
> Next Seminar - Australia - July/August
> http://www.jlcomp.demon.co.uk/seminar.html
> 
> Host to The Co-Operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> 
> 
> 
> -----Original Message-----
> To: Multiple recipients of list ORACLE-L
> <[EMAIL PROTECTED]>
> Date: 09 May 2002 22:16
> choice
> 
> 
> |Hi Johnathan,
> |
> |here is the skinny:
> |
> |db_file_multiblock_read_count = 64
> |number of rows=15m
> |blocks=251071
> |empty_blocks=0
> |db_block_size=16384
> |
> |total plan cost=4924
> |tablescan cost = 4924
> |
> |Jack
> |
> |
> 
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> -- 
> Author: Jonathan Lewis
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services    -- (858) 538-5051  FAX:
> (858) 538-5051
> San Diego, California        -- Public Internet
> access / Mailing Lists
>
--------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jack Silvey
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to