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

Re: constraints and performance

From: postgres(at)jal(dot)org
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org, jkanter(at)virginia(dot)edu
Subject: Re: constraints and performance
Date: 2004-05-30 22:39:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Wed, 11 Feb 2004, Christopher Browne wrote:

> A long time ago, in a galaxy far, far away, jkanter(at)virginia(dot)edu (Jodi Kanter) wrote:
> > Do constraints effect performance significantly?
> They would be expected to provide a significant enhancement to
> performance over:
>  a) Firing triggers,
>  b) Firing rules, and
>  c) Forcing the application to validate the data, and then adding
>     in "data validation" reports to report on the cases where a buggy 
>     application violated the constraints.
> So yes, they should be considerably faster than any of their
> alternatives.

A completely correct answer, but not the one I suspect Jodi wanted,
which was whether there was a "significant" penalty difference between
using constraints on a table and not using constraints on a table.

I'm not sure I have any better answer, because we don't know what
"significant" means, or the nature of the constraints.

I will share my experience, which is that constraints add little
noticable overhead in simple cases. However, when constraining cascading
deletes through many tables, for instance, it is absolutely noticable. 
Between those two extremes, it isn't "too bad", for me and my 
applications, wherein I rely heavily on constraints (and rules, and
server-side triggers).

I don't think it is possible to say "constraints add an n% overhead", due
to the extreme variability of the way they can be used.

Best practice, as Christopher notes, indicates that they should be used. 
It saves a lot of grief (why write the code in the application layer
when you can the DB authors already have?). If you are in a
situation where the difference between using them and not using them
forms a critical boundary, I would suggest you have some other problems,
either in design or specification.

I realize that may not be helpful, given real world constraints - the
consumers of applications may not be realistic in setting requirements.

One thing to think about carefully, if building an application that has
to scale to any real degree, is the tradeoff between client side and
server side processing. While it is best-practice to keep data
validation close to the data, I have been involved in some projects
where scaling the DB server to the task was not economically possible;
the project would not have happened if that were an enforced criteria.
Messy, bad, poor practice? Yes on all counts. One must be very, very
careful if one chooses to ensure data integrity client-side.

Anyway, getting back to the question, the only real answer is "try it
and see". As far as I know, there's no way to quantify the impact of 
constraints on query performance without taking the data model and 
usage patterns of the application into account.

I hope this helps some.


Jamie Lawrence                                        jal(at)jal(dot)org
There is nothing more demoralizing than a small but adequate income.
   - Edmund Wilson

In response to

pgsql-admin by date

Next:From: Christopher BrowneDate: 2004-05-31 02:22:00
Subject: Re: Postgresql on a shared storage
Previous:From: V i s h a l Kashyap @ [Sai Hertz And Control Systems]Date: 2004-05-29 02:44:21
Subject: Re: ppp link activated on startup

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