Re: Limit on number of values for list partition?

Yeah, I think I was a bit confused too. I was struggling with the idea of how to partition some data that just didn't fit. I have since realised the folly of this and decided to bite the bullet and introduce a column specifically as a partition key.

This seems to look like it will work a charm using list based partitioning but alas our production database is still 8.1.7. For the life of me I cannot see how to do it range based partitions.

The "key" will contain a year and then a session code and will look something like "200340" or "200270" (the "40" and "70" being different sesmesters). Using the list based partition it was easy, create a partition for each major session and off you go. But the range based idea has me a little confused. If I have a range that says LESS THAN ('200341') (to ensure "200340" fits) then does "200270" get placed within this partition? I assume it does unless I create another range for LESS THAN ('200271') but what happens then? "200270" is seemingly suitable for both partitions. I am assuming that Oracle will go for the "best match" and that "200270" will be destined for the "200271" partition otherwise I don't understand how it can ever work. Are these assumptions valid?

Matt.

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:pan.2003.03.04.07.57.17.327346_at_yahoo.com.au...
> On Tue, 04 Mar 2003 00:03:28 +0000, M2 wrote:
>
> > Hi All,
> > I am thinking of using list based partitioning for a date warehousing
> > application. In order to have range based partitioning work for me I
would
> > need to have as many as a 1000-2000 values. Would these kinds of numbers
> > work? Would they be efficient?
> >
>
> I'm a bit confused. List partition is one thing, and range partitioning is
> another. Range partitioning is good for continuum (particularly
> date-based) distributions of data. List partitioning is good for
> explaining to Oracle that you see a relationship between things which it
> wouldn't have a clue about (eg, group together NY, MD, CT and NJ in
> "NORTH_EAST" and stick TX, AZ and CA in "WEST"... there's no alphabetic
> rhymne nor reason to such a grouping, but you see it and understand it).
>
> If it is truly list partitioning you are after, then you are restricted to
> a list of values of 4000 bytes in length per partition. For your 1000 to
> 2000 values, you'd have to be talking about no more than 4, and possibly
> just two, characters per value.
>
> Regards
> HJR
>
>
> > Matt.
>
Received on Tue Mar 04 2003 - 16:11:58 CST