Re: contrib idea

> 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.

Keep in mind that the penalty for no index is a sequential scan, which
_usually_ is a light operation. In fact, many queryes don't even use
indexes if they are going to need to see more than a small portion of
the table.

But yes, if your primary key is changing often, that is a valid issue.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026