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" <[EMAIL PROTECTED]> To: "Alexander Priem" <[EMAIL PROTECTED]> Cc: "Tomasz Myrta" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, August 29, 2003 4:00 PM Subject: Re: [PERFORM] Indexing question > "Alexander Priem" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html