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.
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Alexander Priem" <ap@cict.nl>
Cc: "Tomasz Myrta" <jasiek@klaster.net>; <pgsql-performance@postgresql.org>
Sent: Friday, August 29, 2003 4:00 PM
Subject: Re: [PERFORM] Indexing question
> "Alexander Priem" <ap@cict.nl> writes:
> > Does anyone know whether it is bad practise to have two indexes on the
> > primary key of a table? (one 'primary key' index and one partial index)
>
> It's a little unusual, but if you get enough performance boost from it
> to justify the maintenance cost of the extra index, then I can't see
> anything wrong with it.
>
> The "if" is worth checking though. I missed the start of this thread,
> but what percentage of your rows do you expect to have null deleteddate?
> Unless it's a pretty small percentage, I'm unconvinced that the extra
> indexes will be worth their cost.
>
> regards, tom lane
