Is there any value in using trigger conditions rather than function conditions

From: Bill MacArthur <webmaster(at)dhs-club(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Is there any value in using trigger conditions rather than function conditions
Date: 2013-04-22 16:04:23
Message-ID: 51755F87.3060808@dhs-club.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hello,

We have elements in our setup that have been around for quite awhile. We are currently running 9.2 and I was wondering if there would be any significant performance increase by moving the conditions out of the function into the trigger... like would avoiding the function load save anything.... or would the function be loaded regardless? The function is used by many tables to avoid having to explicitly define the timestamp in every query. We have a similar trig/func setup for recording the DB operator at the moment.

An example trigger:

CREATE TRIGGER update_members_stamp
BEFORE UPDATE
ON members
FOR EACH ROW
EXECUTE PROCEDURE update_stamp();

The shared function:

CREATE OR REPLACE FUNCTION update_stamp()
RETURNS trigger AS
$BODY$
BEGIN
-- if the stamp is being manually manipulated, then we will leave it alone
IF NEW.stamp ISNULL
OR NEW.stamp = OLD.stamp
THEN NEW.stamp := NOW();
END IF;
RETURN NEW;
END;$BODY$
LANGUAGE plpgsql VOLATILE
COST 1;

If we did something like this would there be any real benefit on a moderately busy table? (ideally I would like to embed the action in the trigger but that does not seem possible)

CREATE TRIGGER update_members_stamp
BEFORE UPDATE
ON members
FOR EACH ROW
WHEN NEW.stamp ISNULL OR NEW.stamp = OLD.stamp
EXECUTE PROCEDURE update_stamp_x();

CREATE OR REPLACE FUNCTION update_stamp_x()
RETURNS trigger AS
$BODY$
BEGIN
NEW.stamp := NOW();
END IF;
RETURN NEW;
END;$BODY$
LANGUAGE plpgsql VOLATILE
COST 1;

Browse pgsql-admin by date

  From Date Subject
Next Message Benjamin Krajmalnik 2013-04-22 18:06:52 Failover question
Previous Message German Becker 2013-04-22 16:03:35 archive falling behind