Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Sean ChittendenDate: 2003-08-29 17:03:31
Subject: Re: bad estimates
Previous:From: Ken GeisDate: 2003-08-29 16:56:59
Subject: Re: bad estimates

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group