> I agree with this. The purpose for which we need this feature is to be able to split our Point
> of Sale system databases between the configuration information (and the most recent few days of
> collected data), and the "historical" collected data. Our system has over 200 tables, only about
> 20 of which store sales, timeclock data, security logs, etc. The configuration information plus
> the last few days of (not yet locked) sales data would rarely exceed 100MB, even in a 20GB
> database containing 5 years of sales data for 30 locations. If we can divide this, we can do
> much more frequent backups of the "dynamic" data, and still be able to query the historical data
> for reporting. But we need to be able to join the collected data to the configuration in order
> to do complex where clauses.

Then, i'd said, you need tablespaces with ability to be backed up separately.
But this is another story ;)

Regards,
Vlad