RE: full-scan vs index for "small" tables
- To: <cary.millsap@xxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 28 Jun 2006 12:28:02 -0400
And I'd go so far as to say that a pretty significant number of Category
I cases fall into the class of problems related to data in a table where
columns are correlated with each other. That is, to borrow the example
that Jonathan used in Zurich last week, you have "people born in
December", which is going to be roughly 1/12 of the population. You
have "people whose astrological sign is Taurus", again, roughly 1/12 of
the population. But, what happens when you query "people born in
December whose astrological sign is Taurus"? Well, since Taurus is
folks whose birthdays are April 20th to May 20th, the result is zero.
But, the optimizer doesn't know that, it's expecting 1/144th of the
population.
Cases like the above are where the optimizer can go wrong. It simply
doesn't know enough about the data and it's distribution to make the
correct decision.
-Mark
--
Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning
Ours is the age that is proud of machines that can think and suspicious
of men who try to. --H. Mumford Jones, 1892-1980
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Cary Millsap
Sent: Wednesday, June 28, 2006 12:00 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: full-scan vs index for "small" tables
> ...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
--
//www.freelists.org/webpage/oracle-l
Other related posts: