Re: Indexing question

From: Richard Ellis <rellis9(at)yahoo(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Indexing question
Date: 2003-08-29 16:58:51
Message-ID: 20030829165850.GA28458@i386.dp100.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Aug 29, 2003 at 05:13:52PM +0200, Alexander Priem wrote:
> Well, the intention is to hold every record that ever existed in the table.
> Therefore, records do not get deleted, but they get a date in the
> deleteddate field. This way, we can track what changes were made to the
> table(s).
>
> So if a record gets 'deleted', the field 'deleted' is set to today's date.
> If a record gets 'updated', a new record is made containing the new data,
> and the old record is marked as 'deleted'.
>
> So the percentage of 'deleted' records will grow with time, if you
> understand what I mean.

Did you consider a two table implimentation. 1 table "live_table"
containing the non-deleted records, a second table "deleted_table"
containing the deleted records, along with the "deleted_date" field. Keep
the two in sync column type/number wise, and use a before delete trigger
function on "live_table" to actually insert a copy of the deleted row plus
"deleted_date" into "deleted_table" before performing the delete on
"live_table".

You could also use a before update trigger to keep old copies of updated
records in the same way.

Then you would only incur the performance loss of scanning/etc. the deleted
records when you actually need to pull up deleted plus live records.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Sean Chittenden 2003-08-29 17:03:31 Re: bad estimates
Previous Message Ken Geis 2003-08-29 16:56:59 Re: bad estimates