Partitioning revisited

In a previous post I asserted that range partitioning on date was commonly used in data warehouses. Date partitioning can simplify the 'retiring' of old data, make the fact load more efficient and improve the performance of user queries (after all, most users will include some form of date predicate in their queries). One point I may not developed fully was that range partitioning does not imply uniform ranges. True, a lot of partitioned DW systems have equi-sized ranges for all partitions (say week, or quarter) but there can be benefit in changing the partition range size as the data ages through its life cycle. As usual, what I suggest may well not be suitable for your implementation, but here are some ideas where non-constant ranges might work for you:
You have day level queries for the most recent time periods, but week, quarter and year level queries for the old stuff
You align the partition scheme to the batch load - this gives the potential to use partition exchange in the data load
You have a data aging policy where old stuff gets moved to slower storage, perhaps you have the high-speed access partitioned by week and the slower stuff by quarter.

Of course there is some development work you will need to do to implement this approach. In particular you will need to develop the functionality to merge partitions; this, of course, could be coupled with the implementation of data compression, moving to slower storage or setting tablespaces to read only