Re: Inheritence versus delete from

From: John Arbash Meinel <john(at)arbash-meinel(dot)com>
To: Sven Willenberger <sven(at)dmv(dot)com>
Cc: Postgresql Performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Inheritence versus delete from
Date: 2005-03-01 01:41:20
Message-ID: 4223C840.1060109@arbash-meinel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message PFC 2005-03-01 05:32:14 Re: seq scan cache vs. index cache smackdown
Previous Message Tom Lane 2005-03-01 01:07:20 Re: Inheritence versus delete from