if we have the following trigger:
CREATE TRIGGER admin_update_trigger
BEFORE UPDATE ON admin_logger_overflow
FOR EACH ROW
WHEN ((old.start_date_time IS DISTINCT FROM new.start_date_time))
EXECUTE PROCEDURE update_logger_config();
BEFORE UPDATE ON admin_logger_overflow
FOR EACH ROW
WHEN ((old.start_date_time IS DISTINCT FROM new.start_date_time))
EXECUTE PROCEDURE update_logger_config();
and the database call issues an: update admin_logger_overflow set stop_date_time = '2013-10-31 15:00:00'::timestamp where admin_update_id = 1; Does the trigger fire? No, Right?
if the next database call issues an: update admin_logger_overflow set start_date_time = '2013-10-31 13:59:58'::timestamp where admin_update_id = 1; Does the trigger fire? Yes, No doubt
but if the very next database call issues an: update admin_logger_overflow set
start_date_time = '2013-10-31 13:59:58'::timestamp, stop_date_time = '2013-10-31 16:29:37'::timestamp where admin_update_id
= 1;
where the
start_date_time timestamp value is identical to the one in the prior update statement, is it true that the admin_update_trigger is still being fired because the WHEN IS DISTINCT FROM condition still has to be evaluated and depending upon its condition
the determination is made if the EXECUTE PROCEDURE call is going to happen or not? Yes, Right?
We have processes that perform thousands and thousands of these updates and these data ingest processes are taking a measurable performance hit when the trigger is being fired repeatedly, as opposed to when this trigger is removed from the ingest workflow.
Does removing the start_date_time column from the update column list when the value is redundant circumvent the trigger call from happening, and thus reducing the performance hit on these update statements?
thanks
