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

From Daniel Åkerud
Subject Re: Foreign Keys Constraints, perforamance analysis
Date
Msg-id 007901c0fd86$d3e6b0d0$c901a8c0@automatic100
Whole thread Raw
In response to Foreign Keys Constraints, perforamance analysis  (Daniel Åkerud <zilch@home.se>)
List pgsql-general
> > Agreed, but I don't want to measure the performance of real-world
> > application anyway, I just want
> > to issolate how much you loose having the database manager handle the
> > deletion for you, as the ON DELETE
> > CASCADE foreign key constraint does.
>
> That doesn't make any sense.  There's no performance in the abstract,
> only with regard to actual cases.
>
> You might as well say, "I don't want to measure the performance of
> any real CPU, but only the theoretical performance of various CPU
> designs using imaginary data."  You'll probably get a number, but it
> won't refer to anything.
>

You have a good point there, but it has nothing to do with what I am
doing...
You assume I will conclude that there is X loss in performance and then
that's it. However that is not the case here. The results will be
generalised in time and then the numbers have no meaning in the big case.
I'm writing a big chapter about foreign keys and foreign keys constraints in
general (thanks Jan Wieck) and I just want to show that there _is_ actually
performance loss. Thats all. Most of the chapter will explain what you GAIN
having them! :)

Thanks.

Daniel Åkerud



pgsql-general by date:

Previous
From: "Brent R. Matzelle"
Date:
Subject: Re: Red Hat to support PostgreSQL
Next
From: Bruce Momjian
Date:
Subject: Re: What's it: NOTICE: Adding missing FROM-clause entry