Re: Indexing question

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(at)sss(dot)pgh(dot)pa(dot)us>
To: "Alexander Priem" <ap(at)cict(dot)nl>
Cc: "Tomasz Myrta" <jasiek(at)klaster(dot)net>; <pgsql-performance(at)postgresql(dot)org>
Sent: Friday, August 29, 2003 4:00 PM
Subject: Re: [PERFORM] Indexing question

> "Alexander Priem" <ap(at)cict(dot)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