Discussion:
constraints and performance
(too old to reply)
Jodi Kanter
2004-02-11 13:21:01 UTC
Permalink
Do constraints effect performance significantly?
Thanks
Jodi
--
/_______________________________
//Jodi L Kanter
BioInformatics Database Administrator
University of Virginia
(434) 924-2846
***@virginia.edu <mailto:***@virginia.edu>/



/ /

/ /
Christopher Browne
2004-02-11 14:06:46 UTC
Permalink
Post by Jodi Kanter
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.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','ntlug.org').
http://cbbrowne.com/info/lsf.html
"The only constructive theory connecting neuroscience and psychology
will arise from the study of software."
-- Alan Perlis
[To the endless aggravation of both disciplines. Ed.]
p***@jal.org
2004-05-30 22:39:31 UTC
Permalink
Post by Christopher Browne
Post by Jodi Kanter
Do constraints effect performance significantly?
They would be expected to provide a significant enhancement to
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.

-j
--
Jamie Lawrence ***@jal.org
There is nothing more demoralizing than a small but adequate income.
- Edmund Wilson



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
scott.marlowe
2004-02-11 16:01:31 UTC
Permalink
Post by Jodi Kanter
Do constraints effect performance significantly?
That depends.

Foreign key constraints on int4 columns or int8 columns (matching of
course) are usually quite fast.

FK constraints on non-int (numeric, text, etc...) tend to be slower.

check constraints can be a killer if they are complex or use functions,
but simple check constraints are usually alright.

Do you have a specific use case you're looking at?


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Loading...