Re: partitioned table advice

in article 3c193f41.87010724_at_ausnews.austin.ibm.com, Ed Stevens at Ed_Stevens_at_nospam.noway.nohow wrote on 12/13/01 3:59 PM:

> Platform; Oracle 8.0.5 SE, NT4
>
> We've never used a partitioned table before, but I'm looking at a candidate.
> A
> SELECT DISTINCT on the primary key shows seven different values. The
> distribution of rows across these values is as follows:
>
> value 1 - 17,814 rows
> value 2 - 322 rows
> value 3 - 36,976 rows
> value 4 - 29,580 rows
> value 5 - 228 rows
> value 6 - 1,565 rows
> value 7 - 371 rows
>
> The app is heavy in queries with a "WHERE =" on this column.
>
> Would the skewing of the column values argue for or against partitioning on
> this
> column? Or is the answer still "it depends -- we need more info about which
> distinct values are most often queried."
>
>
> --
> Ed Stevens
> (Opinions expressed do not necessarily represent those of my employer.)

1. You're on SE - partitioning is an Option to EE, so it will cost twice (once to upgrade to EE, the again for the partitioning option)
2. Partitioning for data management is overkill - you simply don't have enough data to make partitioning worthwhile
3. It's not clear what your actual problem is, but if it's performance differences between queries on the small value sets versus the large value sets, then look at indexing and even potentially histograms (presuming you are using the CBO for the latter, of course). See http://otn.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/ a76992/stats.htm#27027 - but also check that histograms are an SE feature.