Re: good value for optimizer_index_cost_adj

I've got it on my list of things I'd like to do (i.e. understand DBMS_STATS.GATHER_SYSTEM_STATS), but I don't see any time to do it anytime soon. :-(

It makes sense that the use of this procedure should obsolesce both OPTIMIZER_INDEX_xxxx parameters...

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Wednesday, April 24, 2002 2:48 PM

> It's interesting that you should have heard that.
>
> My first interpretation of the optimizer_index_cost_adj
> was that it was an estimate of the table logical I/O that
> would become physical I/O (and ignore the fact that
> this was allowed to go above 100%) - which brings
> it into line, somewhat, with the optimizer_index_caching
> in terms of 'addressing the same issue'.
>
> However, I decided that your interpretation was
> a much nicer, more intuitive, way of appreciating
> the significance of the number and deciding on
> a rational setting for it.
>
> But I'm inclined to agree with you - even if they were
> supposed to be addressing the same problem in
> different ways, they do seem to be jointly and
> separately (as the lawyers say) viable.
>
> Have you tried any experiments yet which
> mix dbms_stats.system_stats figures with
> the effects of these two parameters ? That
> ought to be a case of when we should do one
> or the other.
>
> 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-----
>
> At IOUG-A, I heard discussion that the OPTIMIZER_INDEX_CACHING and
> OPTIMIZER_INDEX_COST_ADJ were two separate approaches developed by
> different
> development teams within Oracle that had the exact same purpose. So,
> the
> argument was advanced that setting *either* one *or* the other was
> sufficient, but not *both*. Not having any access to the internal
> goings-on
> in Oracle ST Development, I'm sticking with the idea that these two
> parameters are addressing *different* and very specific issues, so
> they both
> should be considered and used independently of one another...
>
> I have a paper on this topic at
> http://www.EvDBT.com/SearchIntelligenceCBO.doc that discusses these
> issues
> in more depth...
>
>
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Jonathan Lewis
> INET: jonathan_at_jlcomp.demon.co.uk
>
> 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: ListGuru_at_fatcity.com (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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tim Gorman
  INET: Tim_at_SageLogix.com

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: ListGuru_at_fatcity.com (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).