Обсуждение: 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/