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

Re: contrib idea

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib idea
Date: 2001-12-21 04:29:16
Message-ID: 16101.1008908956@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> If you have a foreign key on a column, then whenever the primary key is
>> modified, the following checks may occur:
>> 
>> * Check to see if the child row exists (no action)
>> * Delete the child row (cascade delete)
>> * Update the child row (cascade update)
>> 
>> All of which will benefit from an index...

> OK, then perhaps we should be creating an index automatically?  Folks?

We should not *force* people to have an index.  If the master table very
seldom changes, then an index on the referencing table will be a net
loss (at least as far as the foreign-key ops go).  You'll pay for it on
every referencing-table update, and use it only seldom.

Possibly there should be an entry in the "performance tips" chapter
recommending that people consider adding an index on the referencing
column if they are concerned about the speed of updates to the
referenced table.  But I dislike software that considers itself smarter
than the DBA.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-12-21 04:29:29
Subject: Re: The dbase conrtib doesn't compile
Previous:From: Bruce MomjianDate: 2001-12-21 04:28:40
Subject: Re: The dbase conrtib doesn't compile

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