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

Re: performance of foreign key constraints

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: teknokrat <teknokrat(at)yahoo(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: performance of foreign key constraints
Date: 2003-08-28 18:51:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thu, 28 Aug 2003, teknokrat wrote:

> Stephan Szabo wrote:
> > On Thu, 28 Aug 2003, teknokrat wrote:
> >
> >
> >>I have a table that has about 20 foreign key constraints on it. I think
> >>this is a bit excessive and am considering removing them ( they are all
> >>related to the same table and I don't think there is much chance of any
> >>integrity violations ). Would this improve performance or not?
> >
> >
> > It depends on your frequency of inserts/updates to the table with the
> > constraint and the frequency of update/delete to the table(s) being
> > refered to. My guess is probably.  You may wish to leave some of the
> > constraints (decide which are the most important), but 20 does seem a bit
> > excessive in general.
> >
> The references are all to the same table i.e. they are employee ids, so
> leaving some and not others would make no sense. The table has no
> deletes, small amount of inserts and moderate amount of updates. However
> there are many selects and its their performance I am most concerned with.

The foreign keys should only really affect insert/update/delete
performance.  If you're using 7.3.4 (I think) then updates to the fk table
that don't change any of the keys should be relatively cheap.  I'd be much
more worried if you had any changes the the referenced employee table that
might change the key because that could get relatively expensive.

In response to

pgsql-performance by date

Next:From: Anders K. PedersenDate: 2003-08-28 18:57:02
Subject: Re: Queries sometimes take 1000 times the normal time
Previous:From: Stephan SzaboDate: 2003-08-28 18:49:00
Subject: Re: Simple queries take forever to run

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