From: | Robert Klemme <shortcutter(at)googlemail(dot)com> |
---|---|
To: | mark <dvlhntr(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Deferred constraints performance impact ? |
Date: | 2012-08-13 08:33:24 |
Message-ID: | CAM9pMnMinr95msZ7JV2LP6sEJsvNDdXttRUhdfVp1YC5ziPkUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Jul 20, 2012 at 4:27 AM, mark <dvlhntr(at)gmail(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-08-13 19:40:28 | Re: Postgres 9.1.4 - high stats collector IO usage |
Previous Message | David Barton | 2012-08-13 02:17:28 | Re: Postgres 9.1.4 - high stats collector IO usage |