Sven Willenberger wrote:
Trying to determine the best overall approach for the following scenario:
Each month our primary table accumulates some 30 million rows (which could very well hit 60+ million rows per month by year's end). Basically there will end up being a lot of historical data with little value beyond archival.
If this statement is true, then 2 seems the best plan.
2) Each month: SELECT * INTO 3monthsago_dynamically_named_table FROM bigtable WHERE targetdate < $3monthsago; DELETE FROM bigtable where targetdate < $3monthsago; VACUUM ANALYZE bigtable; pg_dump 3monthsago_dynamically_named_table for archiving;
It seems like this method would force the table to stay small, and would keep your queries fast. But if you ever actually *need* the old data, then you start having problems.
...
I think (3) would tend to force a whole bunch of joins (one for each child table), rather than just one join against 3months of data.
Any takes on which approach makes most sense from a performance and/or maintenance point of view and are there other options I may have missed?
Sven Willenberger
If you can get away with it 2 is the best.
John =:->
signature.asc
Description: OpenPGP digital signature
