From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jim(at)nasby(dot)net |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: ERROR: Memory exhausted in AllocSetAlloc(188) |
Date: | 2003-05-21 21:03:14 |
Message-ID: | 11909.1053550994@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> On Wed, May 21, 2003 at 04:39:18PM -0400, Tom Lane wrote:
>> Each pending deferred-trigger action takes about 40 bytes + palloc
>> overhead, probably 48 bytes altogether ... 48 * 35M comes to 1.68G, so
>> that's exactly where your problem is. I'd suggest trying to commit the
>> changes in smaller batches ...
> Ugh... would two triggers double that? Where can I get more info on
> what's happening under the covers here, especially on what a deferred
> trigger is?
A deferred trigger is an AFTER trigger. If you can do your work in
BEFORE triggers, you should.
Two triggers firing on the same row action (insert/update/delete) do not
double the memory --- there's one trigger queue entry per action. It
looks like it costs about 8 more bytes for each additional deferred
trigger that needs to be fired on the same row action.
Beyond that, read the code --- it's in backend/commands/trigger.c.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Ayers | 2003-05-21 21:16:32 | Re: "IN" statement causing execution cancel? |
Previous Message | Andrew Sullivan | 2003-05-21 20:57:21 | Re: VACUUM and transaction ID wraparound |
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-05-21 21:15:21 | Re: Removing width from EXPLAIN |
Previous Message | Andrew Sullivan | 2003-05-21 20:52:04 | Re: Heads up: 7.3.3 this Wednesday |