From: Bruce Momjian Date: Tue, 4 Nov 2008 00:59:45 +0000 (+0000) Subject: Remove tabs from SGML file. X-Git-Tag: REL8_4_BETA1~764 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ac3797a913f0a9a9b7e04f97a866c8ee6dd785b1;p=postgresql Remove tabs from SGML file. --- diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 0aaf4c1b48..e272b8b6ee 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -1,4 +1,4 @@ - + Functions and Operators @@ -12855,46 +12855,46 @@ SELECT (pg_stat_file('filename')).modification; Currently PostgreSQL provides one built in trigger - function, suppress_redundant_updates_trigger, - which will prevent any update - that does not actually change the data in the row from taking place, in - contrast to the normal behaviour which always performs the update - regardless of whether or not the data has changed. (This normal behaviour - makes updates run faster, since no checking is required, and is also - useful in certain cases.) + function, suppress_redundant_updates_trigger, + which will prevent any update + that does not actually change the data in the row from taking place, in + contrast to the normal behaviour which always performs the update + regardless of whether or not the data has changed. (This normal behaviour + makes updates run faster, since no checking is required, and is also + useful in certain cases.) - - Ideally, you should normally avoid running updates that don't actually - change the data in the record. Redundant updates can cost considerable - unnecessary time, especially if there are lots of indexes to alter, - and space in dead rows that will eventually have to be vacuumed. - However, detecting such situations in client code is not - always easy, or even possible, and writing expressions to detect - them can be error-prone. An alternative is to use - suppress_redundant_updates_trigger, which will skip - updates that don't change the data. You should use this with care, - however. The trigger takes a small but non-trivial time for each record, - so if most of the records affected by an update are actually changed, - use of this trigger will actually make the update run slower. + + Ideally, you should normally avoid running updates that don't actually + change the data in the record. Redundant updates can cost considerable + unnecessary time, especially if there are lots of indexes to alter, + and space in dead rows that will eventually have to be vacuumed. + However, detecting such situations in client code is not + always easy, or even possible, and writing expressions to detect + them can be error-prone. An alternative is to use + suppress_redundant_updates_trigger, which will skip + updates that don't change the data. You should use this with care, + however. The trigger takes a small but non-trivial time for each record, + so if most of the records affected by an update are actually changed, + use of this trigger will actually make the update run slower. The suppress_redundant_updates_trigger function can be - added to a table like this: + added to a table like this: CREATE TRIGGER z_min_update BEFORE UPDATE ON tablename FOR EACH ROW EXECUTE PROCEDURE suppress_redundant_updates_trigger(); In most cases, you would want to fire this trigger last for each row. - Bearing in mind that triggers fire in name order, you would then - choose a trigger name that comes after the name of any other trigger + Bearing in mind that triggers fire in name order, you would then + choose a trigger name that comes after the name of any other trigger you might have on the table. - + For more information about creating triggers, see - . + .