Path: news.easynews.com!easynews!hub1.nntpserver.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!newsfeed01.tsnz.net!newsfeeds.ihug.co.nz!lust.ihug.co.nz!ihug.co.nz!not-for-mail From: "Howard J. Rogers" Newsgroups: comp.databases.oracle.server Subject: Re: analyze index and cost Date: Mon, 4 Mar 2002 11:30:01 +1100 Organization: ihug ( New Zealand ) Lines: 84 Message-ID: References: <3C7FAAE9.C3F26803@ci.seattle.wa.us> NNTP-Posting-Host: p265-apx1.syd.ihug.com.au X-Trace: lust.ihug.co.nz 1015201808 7139 203.173.141.11 (4 Mar 2002 00:30:08 GMT) X-Complaints-To: abuse@ihug.co.nz NNTP-Posting-Date: Mon, 4 Mar 2002 00:30:08 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: easynews comp.databases.oracle.server:137325 X-Received-Date: Sun, 03 Mar 2002 17:28:03 MST (news.easynews.com) No, quite the opposite. In the absence of statistics, the optimizer uses rule-based optimization, and one of the earliest of the (I think it's 15) rules is 'if there's an index available, use it' -even if it doesn't actually make sense to do so. The point is that by computing statistics, you give the cost-based optimizer a chance to work out whether it would *really* make sense to use the index. In your case, it would appear that the optimizer has decided it would be cheaper not to bother -though clearly, it would seem as if it is making a mistake in arriving at that conclusion. Working out why that's happening I'll leave to others (Jonathan??!)... but it might be, for example, that db_file_multiblock_read_count is set so high that full table scans appear to the optimizer to be ridiculously cheap. But there's heaps of other potential reasons, and even Jonathan can't answer the question until he sees the precise nature of the tables, indexes and query involved. All I wanted to point out here is that computing statistics does NOT mean 'things go faster', it means that the optimizer has some basis on which to work out an *intelligent* approach to getting at the data, rather than just blindly following a set of 15 rules that haven't changed in years. Usually that *would* mean performance improvements, but there are plenty of configuration and coding issues which can stop that happening. They need to be diagnosed and resolved -and that simply can't be done in the absence of any further information from you. Regards HJR -- ---------------------------------------------- Resources for Oracle: http://www.hjrdba.com =============================== "achkar" wrote in message news:acb78eab.0203031619.4307b35b@posting.google.com... > Hi , > > The optimizer does a full table scan when I compute statistics , but > if there is no statistics ,the optimiser uses that index , now this is > my point Why the optimizer does that , I though it would be faster > when I compute statistics but it is not , > > Regards, > Achkar > > > damorgan wrote in message news:<3C7FAAE9.C3F26803@ci.seattle.wa.us>... > > Excellent advise. If that doesn't solve it post the query, the explain plan, > > a list of indexes on the table(s), and the number of rows. > > > > Are you using any hints? > > > > Daniel Morgan > > > > > > > > santosh sharma wrote: > > > > > did you compare the explain plan before and after compute stat ? It will > > > point you why this is happening. > > > > > > HTh > > > santysharma > > > > > > "achkar" wrote in message > > > news:acb78eab.0202281707.34303a16@posting.google.com... > > > > Hi All , > > > > > > > > I have a big query , it takes 70 min to run , cost is 94819 , when I > > > > create and index ( XXX ) on one of the tables , the cost drops down to > > > > 53770 and takes 30 min to run , but when I do this : analyze index XXX > > > > compute statistics , the cost goes up to 94819 again , I dont > > > > understand why? > > > > > > > > thanks in advance