> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026