From: | Ben Chobot <bench(at)silentmedia(dot)com> |
---|---|
To: | Maria(dot)L(dot)Wilson-1(at)nasa(dot)gov |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: postgres constraint triggers |
Date: | 2011-09-27 04:54:10 |
Message-ID: | 3F7F288F-A4DC-4AFD-B538-FD6C9A943C65@silentmedia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sep 26, 2011, at 10:52 AM, Maria L. Wilson wrote:
> Our first try to solve this problem has been to convert these triggers into a constraint trigger which allows for DEFERRABLE INITIALLY DEFERRED flags. This, we are finding, is forcing the trigger function to run after the triggering transaction is completed. We believe this will fix our locking problem and hopefully speed up our inserts again.
>
> Any comments or past experiences would certainly be helpful!
My memory is fuzzy but as I recall, a possible downside to using deferred constraints was increased memory usage, though I cannot see how at the moment. Regardless, I think the upshot is that they aren't without their cost but as long as you aren't doing massive transactions that cost is probably one that you can afford to pay without much worry.
From | Date | Subject | |
---|---|---|---|
Next Message | Samuel Gendler | 2011-09-27 05:06:26 | Re: Performance Anomaly with "col in (A,B)" vs. "col = A OR col = B" ver. 9.0.3 |
Previous Message | Tom Lane | 2011-09-27 04:21:22 | Re: Ineffective autovacuum |