Best practices for update timestamp with/without triggers

From: "Verghese, Riya" <rverghese(at)cobalt(dot)com>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Best practices for update timestamp with/without triggers
Date: 2014-04-22 01:16:15
Message-ID: CF7B10ED.4EEE2%rverghese@cobalt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi
I am going to add a new column to a table for modify_date that needs to be updated every time the table is updated. Is it better to just update application code to set the modify_date to current_time, or create a Before-Update trigger on the table that will update the modify_date column to current_timestamp when the table is updated? I also have slony in place, so the trigger will need to be on master and slave. Slony will take care of suppressing it on the slave and enabling in the event of a switchover, but it is additional overhead and validation to make sure nothing failed on switchover.
So considering that we have slony, is it better to use application code to update the modify_date or use a trigger?Is a trigger essentially 2 updates to the table? Are there any other risks in using the trigger?

Thanks
Riya Verghese

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tory M Blue 2014-04-22 01:19:49 Best practice question
Previous Message Merlin Moncure 2014-04-21 14:16:29 Re: Fast distinct not working as expected