From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Ben Chobot <bench(at)silentmedia(dot)com> |
Cc: | Maria(dot)L(dot)Wilson-1(at)nasa(dot)gov, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: postgres constraint triggers |
Date: | 2011-09-28 00:37:15 |
Message-ID: | 4E826C3B.7030504@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 09/27/2011 12:54 PM, Ben Chobot wrote:
> 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
That's right. PostgreSQL doesn't currently support spilling of pending
constraint information to disk; it has to keep it in RAM, and with
sufficiently huge deferred updates/inserts/deletes it's possible for the
backend to run out of RAM to use.
> though I cannot see how at the moment.
A list of which triggers to run, and on which tuples, must be maintained
until those triggers are fired. That list has to be kept somewhere.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2011-09-28 00:55:12 | Re: : Tracking Full Table Scans |
Previous Message | Kevin Grittner | 2011-09-27 17:15:43 | Re: : Tracking Full Table Scans |