From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Trigger with WHEN clause (WIP) |
Date: | 2009-10-16 14:10:01 |
Message-ID: | 1255702201.30088.3852.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2009-10-16 at 10:02 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-16 14:24:04 | Re: Trigger with WHEN clause (WIP) |
Previous Message | Tom Lane | 2009-10-16 14:02:07 | Re: Trigger with WHEN clause (WIP) |