Re: Perfomance with Partitioning

Can wrote:

> Hi,
>
> I've got a table holding data dispersed over a period of 1 year....but I
> often just need access to the last week. Well, the first thing I thought of,
> was: I could improve the access performance on the last week's data perhaps
> by partitioning the table...
>
> The actual question is: Is there a way of "structuring" my table in such a
> way that the partition holding last week's data never holds more than last
> week's data (->as soon as the data becomes old, it would have to move into a
> different partition)?
> A range partition over the "date" column of the table would fullfill the
> first requirement (=last week's data) but, but the size of the last
> week-partition would grow because of new data being inserted into the same
> partition...
> My goal is to keep the last week-partition permanently as small as possible,
> in order to achieve a performance gain.
>
> Hmm, does anyone have any ideas? (Maybe it's a default issue with a standard
> answer :))
> Thanks in advance...
>
> Kind regards,
> Can
>
>

You can define a partition 52 right now. That's in the future. There are some traps re partitioning - make sure you pick the right method of partitioning, or you cannot add partitions later (unless you rebuild the table)

Take care, and look into that before you go.

BTW - wouldn't an index help? You problem suggests FTS are performed while only retrieving a small portion of the table.

Version (and OS) info are missing.

-- 
Regards, Frank van Bortel