| From: | Ben Chobot <bench(at)silentmedia(dot)com> |
|---|---|
| To: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: postgres constraint triggers |
| Date: | 2011-09-30 03:01:33 |
| Message-ID: | 29A53C6F-24CB-4A60-8725-6ADCD15B083B@silentmedia.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sep 27, 2011, at 6:37 PM, Craig Ringer wrote:
> On 09/27/2011 12:54 PM, Ben Chobot wrote:
>>
>> 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.
Well when you put it like that, it's so obvious. :)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2011-09-30 03:08:19 | Re: array_except -- Find elements that are not common to both arrays |
| Previous Message | bricklen | 2011-09-30 02:32:43 | array_except -- Find elements that are not common to both arrays |