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
=:->