Re: postgres constraint triggers

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.

In response to

Responses

Browse pgsql-performance by date

  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