Re: How's this for space saving:

Last time I looked, the validate command basically read the entire index in leaf block order. (It probably skipped up and down
the branch blocks at the same time, but I wasn't checking that closely).

If it simply reads the index in sequence, then it shouldn't be too hard to write a bit of code that keeps N running totals
in play to track the cumulative size of
the index leaf entries at N different levels of compression.

Regards

Jonathan Lewis

Now waiting on the publishers: Cost Based Oracle - Volume 1

http://www.jlcomp.demon.co.uk/faq/ind_faq.html The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/appearances.html Public Appearances - schedule updated 8th July 2005

• Original Message ----- From: "Bruce McCartney" <bruce.mccartney_at_dbinfosystems.com> To: <jonathan_at_jlcomp.demon.co.uk>; <oracle-l_at_freelists.org> Sent: Wednesday, July 13, 2005 4:53 PM Subject: RE: How's this for space saving:

> Hi Johnathon,
> We got caught trying to use the OPT_CMPR_COUNT to determine if it would be
> benefitial to compress the indexes of a ERP system which had evoved to "an
> index for each report" with massive redundancy in the columns. I posted a
> question to oracle on the algorithm use to calculate that value and got no
> reponse, anyone on the list know what that algorithm might look like?
>
> We saw some very strange values before and after index rebuilds...
>
>

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