Re: Next extent with Locally managed tablespace on 9i

In article
<E2F6A70FE45242488C865C3BC1245DA702741FF4_at_lnewton.leeds.lfs.co.uk>, you said (and I quote):

This is very interesting. Been thinking about it for a while now and haven't yet reached a consensus in my mind. (yes, paranoia is terrible. I rely on consensus)

>
> I'd probably stick with the following :
>
> 64KB, 1MB, 8MB 64MB and if I needed anything larger I'd have to
> consider how big the object is and needs to be.

Hmmm, what about other considerations? Like:
Should we make these somewhat dependent on things like sort_area_size? What about DFMBR? Should we make these uniform chunks match that size or multiples of it?

>
> If you choose a 500 extent threshold, you'll have objects up to the
> following sizes in each tablespace :
>
> 64KB : objects up to 32 MB.

I like this one. Makes sense to me. Small wastage if object is small.

> 1 MB : Objects up to 500MB.

Nope, don't like it. Too "nice". I go straight for 10Mb as the next one.

> 8 MB : objects up to 4 Gb (assuming the IT worl'd propesity for using
> 1000 MB as one GB !) or 4000 MB if you like.

No need, with the 10Mb above.

> 64 MB : Objects up to 32,000 MB (32 GB)
>

Yikes! Nope, no way. Too large. If you have objects THAT large, think partitioning. It's the best way to handle these monsters (with current technology!): divide to conquer.

And so on. Just my $0.02, but the subject is interesting and I'd really like to know other's thoughts on this?

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam