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

The index is only useful where you actually have an on delete or on update
clause. I don't think we want to conditionally create an index. That would
bee too confusing. A contrib, to find "suggested" indexes seems fine.

Andreas

Fri, 21 Dec 2001 09:20:50 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: contrib idea

On Fri, 21 Dec 2001, Zeugswetter Andreas SB SD wrote:

>
> > > 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?
>
> The index is only useful where you actually have an on delete or on update
> clause. I don't think we want to conditionally create an index. That would
> bee too confusing. A contrib, to find "suggested" indexes seems fine.

Actually, even without an on delete or on update it would be used (for the
check to see if there was a row to prevent the action), however autocreate
seems bad.  The contrib thing sounds cool, another vote that way.



Fri, 21 Dec 2001 13:44:16 -0800 (PST)
Stephan Szabo <sszabo@megazone23.bigpanda.com>
Re: contrib idea
> > > * 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?
>
> The index is only useful where you actually have an on delete or on update
> clause.

Hmm...not necessarily true.  A default 'no action' foreign key still needs
to prevent the parent key from being deleted if the child exists.  This
requires that postgres do a search of the child table.

> I don't think we want to conditionally create an index. That would
> bee too confusing. A contrib, to find "suggested" indexes seems fine.

That's what I suggested.

Chris


Mon, 24 Dec 2001 10:49:57 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: contrib idea