Re: Foreign keys - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: Foreign keys
Date
Msg-id 45044013.8020003@commandprompt.com
Whole thread Raw
In response to Re: Foreign keys  (Gregory Stark <gsstark@mit.edu>)
Responses Re: Foreign keys  (Kevin Brown <kevin@sysexperts.com>)
Re: Foreign keys  ("Jim C. Nasby" <jimn@enterprisedb.com>)
List pgsql-hackers
> In any case the same logic that leads to it being desirable to report all the
> errors to the user in a UI and not just report them one by one also applies to
> the database. I'm not sure it's the most important issue in the world, but it
> does seem like a "it would be nice" feature if it reported all the errors in
> the statement, not just the first one it finds.
> 

Seems kind of extraneous to me. I am guessing it would cause yet further 
overhead with our foreign key checks.

My testing shows that the use of foreign keys on high velocity single 
transaction loads, can cause easily a 50% reduction in performance. Why 
add to that? What we need to be doing is finding a way to decrease the 
impact of foreign key checks.

Sincerely,

Joshua D. Drake

-- 
   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240   Providing the most comprehensive  PostgreSQL
solutionssince 1997             http://www.commandprompt.com/
 




pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Foreign keys
Next
From: Stephan Szabo
Date:
Subject: Re: Foreign keys