Re: Index compression vs. table compression

Note in-line

Regards

Jonathan Lewis

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

http://www.jlcomp.demon.co.uk/seminar.html Public Appearances - schedule updated Jan 21st 2005

"Joel Garry" <joel-garry_at_home.com> wrote in message news:1106608143.557574.311600_at_z14g2000cwz.googlegroups.com...
>
> Interesting point brought up here. I've long thought Oracle is kind of
> stingy in it's LOV.

    Fortunately that's a front-end thing, not a database thing,     so we can sympathise with you without having to tell     you how to fix it. ;)

> I'm fortunate that the tool I use makes it
> trivial to do
> such things, since what used to be small lookup tables have inevitably
> had a composite key prepended to allow multiple
> companies/divisions/countries/language/whatever.

    Ah! the old "I don't know how to do a proper design, so     I'll let the DBA sort out the problems." strategy so loved     by 'database independent' apps.

    I sympathise (again). You may be able play around with     singe table index clusters to colocate data for the same class,     or use list partitioning to better effect.

>
> I also liked Richard's recent simplified explanation of the low
> percentage of rows to trigger an FTS, I thought it kind of explained
> the default of the optimizer_index* parameters, although now I need
> another explanation why they need to be changed... :-O
>

    They need to be changed because no one set of values is good     for every application. In fact, no one set of values is perfect for     a single application, and an unlucky choice of values could solve     90% of your problems, and introduce a baffling new 10% that     makes things even worse. There's an article of mine about one     of the parameter at www.dbazine.com with the title:

        "Oh, I see a problem"

> jg
> --
> @home.com is bogus.
> firegoogle: http://weblogs.mozillazine.org/ben/archives/007366.html
>
Received on Tue Jan 25 2005 - 02:49:06 CST