Re: [HACKERS] Reducing the memory footprint of large sets of pending triggers

2008-10-25 Thread Gregory Stark
Tom Lane <[EMAIL PROTECTED]> writes: > Simon Riggs <[EMAIL PROTECTED]> writes: >> A much better objective would be to remove duplicate trigger calls, so >> there isn't any build up of trigger data in the first place. That would >> apply only to immutable functions. RI checks certainly fall into th

Re: [HACKERS] Reducing the memory footprint of large sets of pending triggers

2008-10-25 Thread Simon Riggs
On Sat, 2008-10-25 at 08:48 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > A much better objective would be to remove duplicate trigger calls, so > > there isn't any build up of trigger data in the first place. That would > > apply only to immutable functions. RI checks certa

Re: [HACKERS] Reducing the memory footprint of large sets of pending triggers

2008-10-25 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > A much better objective would be to remove duplicate trigger calls, so > there isn't any build up of trigger data in the first place. That would > apply only to immutable functions. RI checks certainly fall into that > category. They're hardly "duplicates"

Re: [HACKERS] Reducing the memory footprint of large sets of pending triggers

2008-10-25 Thread Simon Riggs
On Thu, 2008-10-23 at 21:32 -0400, Tom Lane wrote: > We've occasionally talked about allowing pending-trigger-event lists to > spill to disk when there get to be so many events that it's a memory > problem. I'm not especially interested in doing that right now, but > I noticed recently that we c

[HACKERS] Reducing the memory footprint of large sets of pending triggers

2008-10-23 Thread Tom Lane
We've occasionally talked about allowing pending-trigger-event lists to spill to disk when there get to be so many events that it's a memory problem. I'm not especially interested in doing that right now, but I noticed recently that we could alleviate the problem a lot by adopting a more compact r