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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]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