Quote Originally Posted by marist89
why? A table is a table is a table. You'd have to check the query plans, but assuming you picked a decent partitioning key, you're all set.
A Partitioned table is not a table....

A table that is partitioned is a different storage mechanism. Requiring appropriate infrastructure to maintain it. That is unless you have a fixed mechanism and fixed partitioning. Implementing rolling date partitioning takes a bit of code to make work correctly. Something that is probably out of the original Posters technical skill to implement considering the question asked.

Quote Originally Posted by marist89
not true, just exchange partition with the big table. segments stay the same, just the data dictionary is updated.
I think you've missed the point of the question I was answering. Please re-read, I'm sure He'd run into space issues due to re-organizing a single large unpartitioned table into a table that is partitioned into smaller more manageable units.


Quote Originally Posted by marist89
definitely requires testing, although seems like a lot of work just to delete some data.
Well at least we both agree testing is a good idea.