RE: Early 11g Advanced Table Compression #'s

I've read this particular post several times. I just have to believe that
I'm not getting something here, because ..... I want to be charitable but
the point that is being made is just asinine in my opinion. I hope, I really
hope, that I've missed something obvious and that I'm the fool (would not be
the first time - I freely confess my imperfections).

>> The common nonsense peddled is like: It all depends.
EXCUSE ME????? Common nonsense? The whole scientific method is all about
Ceter?s paribus. Research is influenced heavily on IT DEPENDS. Drop a rock
and a feather on the Earth and then on the moon and tell me the results are
not a matter of IT DEPENDS. I must have missed your point, because nobody
could be so short sighted as to presuppose that there are no dependencies.

Can you explain negative cases? Sure. I can explain the negative case of the
rock falling faster than the feather to the difference in location and
criteria of the experiment. I can explain Roby's negative results in
numerous ways, including accepting the *possibility* that his results
reflect truth, and that compression is a performance killer. Did he provide
sufficient evidence to review his results, of course not. How do we know the
issue isn't one of the optimizer changing the plan, as opposed to the
physical implementation of compression, for example? We don't because no
execution plans were provided. Ceter?s paribus Ceter?s paribus Ceter?s
paribus Ceter?s paribus Ceter?s paribus Ceter?s paribus !!!

That being said, his results do not mirror mine. Explain that negative case.
Oh, is it because my results are on Oracle Beta 5? Or is it that my results
are on a faster CPU? Can we always explain negative cases? No. Sometimes
because the cost of explaining the negative case does not justify the time
to do so. Sometimes because we just don't have the knowledge, or we don't
have the proper instrumentation (or it's not technically feasible). Besides
that, we have to acknowledge your ill adored Ceter?s paribus in order to
provide an opportunity of finding that negative case explanation.

The result of compression, for example, DEPENDS on CPU speed DEPENDS on blah
blah blah. Execution plans DEPEND on a whole host of things. Writings of the
great ones are full of DEPENDENCIES. Look at Jonathan's book for example, an
amazing study of the CBO. Yet, what is one of the first things he gives us
on page 10? DEPENDENCIES. Settings of various parameters that fairly well
assure that his results will be your results. Change the dependencies and
the results may well change. Sure we could plow through the results and try
to ascertain why his results are different than ours, but it's a lot easier
to deal with dependencies on the front end than trying to figure out what
they are on the back end of a negative experiment.

Additionally, I argue that one can never, ever, systematically prove
everything 100%. Perhaps to a high degree of confidence, but never for sure.
Why? Because the conditions of that result and that analysis can change
because the dependencies change. You can not control the entire environment,
thus you can not 100% guarantee an outcome, ever. If you have never had the
frustrating experience of having two different result sets and not being
able to figure out why they differ, then you are luckier than I (or younger,
or you have more time or less experience).

Dependencies abound, and I do not think that Jonathan or Tom Kyte, or Cary
Millsap or any of the others who's faces should adorn Mount Oracle would
disagree with that conjecture. Given the same set of objects in Oracle 10g,
given the exact same statistics, physical layout of the data, everything
with regards to the data being equivalent, there is still a dependency on
the SYSTEM that the data resides on. Hence, system statistics. On two given
systems, those statistics can be (likely are) different. Even on two systems
that are supposed to be the same, the system statistics can be different.

I would Caution Roby about how he reports his findings, and I'm not all that
wild about the URL name (it is misleading and seems a bit biased). While I
have not tested compression in the production code (yet, I'm running the
book through production now), when I did my chapter on compression in Beta
5, I found the results to be very different from Roby's. Still, I'm glad to
see him testing this stuff and reminding us that not every new feature is a
panacea.

Indeed, Ceter?s paribus is alive and well and worth consideration (and NEVER
tell me I can't preach about something. That's a sure way to get an earful).

Ceter?s paribus Ceter?s paribus Ceter?s paribus Ceter?s paribus Ceter?s
paribus Ceter?s paribus Ceter?s paribus Ceter?s paribus Ceter?s paribus
Ceter?s paribus Ceter?s paribus

Robert

Robert G. Freeman
Oracle Consultant/DBA/Author
Principal Engineer/Team Manager
The Church of Jesus Christ of Latter-Day Saints
Father of Five, Husband of One,
Author of various geeky computer titles
from Osborne/McGraw Hill (Oracle Press)
Oracle Database 11g New Features Now Available for Pre-sales on Amazon.com!
BLOG: http://robertgfreeman.blogspot.com/
Sig V1.2

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Pedro Espinoza
Sent: Friday, August 17, 2007 8:27 AM
To: oracle-l
Subject: Re: Early 11g Advanced Table Compression #'s


I don't consider Roby's test cases are horrible. Anyone who criticizes
the hype seems to be criticized.  Look at the argument of Roby: "But,
then again, if your operations are that minimal, you probably aren't
creating enough data to need compression in the first place!"


Please do not preach me about ceteris paribus clauses used in the
philosophy of sciences.

The common nonsense peddled is like: It all depends. But the question
precisely is this: can one *systematically* explain negative cases?

I am being more charitable with Roby than with the oracle hype, of course!

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


Other related posts: