Re: Deferred constraints performance impact ?
| От | Robert Klemme |
|---|---|
| Тема | Re: Deferred constraints performance impact ? |
| Дата | |
| Msg-id | CAM9pMnMinr95msZ7JV2LP6sEJsvNDdXttRUhdfVp1YC5ziPkUA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Deferred constraints performance impact ? ("mark" <dvlhntr@gmail.com>) |
| Список | pgsql-performance |
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/
В списке pgsql-performance по дате отправления: