Thread: Deferred constraints performance impact ?
Hi all, We have put some deferred constraints (some initially immediate, some initially deferred) into our database for testing with our applications. I haven't seen any noticeable loss in performance, but I am not sure I can properly simulate our full production environment load levels in my tests. I was wondering if I am turning on something that has known significant negative impacts to performance, just from having them there. I understand a lot more may have to be tracked through a transaction and there could be some impact from that. Similar to an after update trigger? Or are the two not comparable in terms of impact from what is tracked and then checked. Anyways, just looking for feedback if anyone has any. -Mark
On Thu, 2012-07-19 at 20:27 -0600, mark wrote: > I understand a lot more may have to be tracked through a transaction and > there could be some impact from that. Similar to an after update trigger? Or > are the two not comparable in terms of impact from what is tracked and then > checked. They should be very comparable to AFTER triggers. It's actually a little better because there are optimizations to avoid queuing constraint checks if we know it will pass. I would recommend testing a few degenerate cases to see how big the impact is, and try to see if that is reasonable for your application. Regards, Jeff Davis
On Fri, Jul 20, 2012 at 4:27 AM, mark <dvlhntr@gmail.com> wrote: > We have put some deferred constraints (some initially immediate, some > initially deferred) into our database for testing with our applications. > I understand a lot more may have to be tracked through a transaction and > there could be some impact from that. Similar to an after update trigger? Or > are the two not comparable in terms of impact from what is tracked and then > checked. Another factor might be the amount of constraint violations you expect: if there are many then deferring the check can create much more work for the DB because you issue more DML as with a non deferred constraint which could create errors much sooner and hence make you stop sending DML earlier. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/