Re: Foreign Keys Constraints, perforamance analysis - Mailing list pgsql-general

From Tom Lane
Subject Re: Foreign Keys Constraints, perforamance analysis
Date
Msg-id 8638.993325815@sss.pgh.pa.us
Whole thread Raw
In response to Foreign Keys Constraints, perforamance analysis  (Daniel Åkerud <zilch@home.se>)
List pgsql-general
=?iso-8859-1?Q?Daniel_=C5kerud?= <zilch@home.se> writes:
> Deleting really showed what the MySQL team means. The deletion was sometime=
> s 30 seconds to < 1 second.

Well, if I understand your rather vague description, you're comparing a
simple bulk delete of all the tuples in the tables, versus a case where
one table sees a bulk delete but the other ones see retail deletion (one
tuple deleted per triggered query, and that tuple has to be searched for
via an indexscan).  Not surprising that it's much slower.  The real
question is what this scenario has to do with production activities.

> If anyone could help, I would really appriciate if someone could tell me wh=
> y the child/child_fkc difference was so much more than the married/married_=
> fkc difference...

That strikes me as odd too, since the one case has only one FK reference
and the other has two ... seems like it should have been the other way
'round.  Experimental noise maybe?  Did you repeat the test to make sure
the numbers were reproducible?  Do you care to post all the details
(scripts etc) so that others can try to reproduce it?

> I doubt is was becuase of the lack of VACUUM ANALYSE.

You *should* be worried about that.  The queries triggered by
foreign-key checks are planned by the regular planner.

            regards, tom lane

pgsql-general by date:

Previous
From: Bryan Field-Elliot
Date:
Subject: Laughable attempt at an insult from the MySQL crowd...
Next
From: Daniel Åkerud
Date:
Subject: ANSI SQL-92 Standard, for download?