RE: full-scan vs index for "small" tables

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 28 Jun 2006 11:00:17 -0500

> ...need stable sql plans.

But the whole point of the CBO is that execution plan stability is
inferior to execution plan adaptation to changing circumstances. As
Jonathan Lewis points out very well, all it takes is the insertion of a
single row to make the True Best Plan change from one execution to
another.

If you truly want plan stability, then you want stored outlines, do you
not?

Certainly, there are two distinct categories where CBO messes up:

 I. Where it has been misinformed by the data it uses to make decisions.
II. Where it makes poor decisions based upon truly representative data.

My experience is that most problems that people think are category II
problems are really category I problems in disguise. The difference can
be revealed by inspection of 10053 data.

I do recognize the existence of category II problems as well. It's just
that I think they're considerably rarer than most people believe.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba
 
Hotsos Symposium 2007 / March 4-8 / Dallas
Visit www.hotsos.com for curriculum and schedule details...

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Laimutis Nedzinskas
Sent: Wednesday, June 28, 2006 10:11 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: full-scan vs index for "small" tables


 
 > On Behalf Of Cary Millsap
 > RBO is dramatically inferior to CBO in every case except for the one
where the operational manager doesn't do a good job of making sure that
the statistics are a reasonable representation of the production data.

OK. To clarify my point:

Case1: In the world where sql developer says literally "a man must not
have to think" CBO is a right thing. Let the software think. 

Case2: in the world "do once and forget" I need stable sql plans. The
"operational manager doesn't do a good job" does not work here. There is
no problem to build even simple counter cases when CBO goes astray. 
What sql developer best practices would be then? 

To the previous list I can think of to add one more:
- bundle "good" statistics into your product setup.







Fyrirvari/Disclaimer
http://www.landsbanki.is/disclaimer
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l


Other related posts: