On Fri, 2009-10-16 at 10:02 -0400, Tom Lane wrote: > Peter Eisentraut <pete...@gmx.net> writes: > > On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote: > >> * It will reduce size of in-memory pending trigger list (for large > >> statements) > > > But this won't be the outcome when it's implemented the way it is being > > proposed, which checks the where clause just before executing the > > trigger function. > > Hm, the feature could actually be worth something if it allows > conditions to be checked before an AFTER trigger event gets pushed > into the event list. However, if it's not doing that ... > > I note BTW that we have some ad-hoc logic already that arranges to > suppress queuing of AFTER events for FK triggers, if the FK column > value has not changed. It might be interesting to look at whether > that hack could be unified with the user-accessible feature. It's > essentially a WHEN OLD.x IS NOT DISTINCT FROM NEW.x test.
If the function is idempotent then we can also optimise away multiple calls by checking whether a similar call is already queued. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
