From 0c2dcb9332ef6d25b4adf8ca918a7083ebb5dcdc Mon Sep 17 00:00:00 2001 From: Tatsuo Ishii Date: Sun, 17 Feb 2019 20:42:14 +0900 Subject: [PATCH] Doc: remove ancient comment. There's a very old comment in rules.sgml added back to 2003. It expected to a feature coming back but it never happened. So now we can safely remove the comment. Back-patched to all supported branches. Discussion: https://postgr.es/m/20190211.191004.219630835457494660.t-ishii%40sraoss.co.jp --- doc/src/sgml/rules.sgml | 24 ------------------------ 1 file changed, 24 deletions(-) diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 6344da95855..d51e435e0bc 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -2434,30 +2434,6 @@ Nestloop in a command. - - - Another situation is cases on UPDATE where it depends on the - change of an attribute if an action should be performed or - not. The only way to - create a rule as in the shoelace_log example is to do it with - a rule qualification. That results in an extra query that is - performed always, even if the attribute of interest cannot - change at all because it does not appear in the target list - of the initial query. When this is enabled again, it will be - one more advantage of rules over triggers. Optimization of - a trigger must fail by definition in this case, because the - fact that its actions will only be done when a specific attribute - is updated is hidden in its functionality. The definition of - a trigger only allows to specify it on row level, so whenever a - row is touched, the trigger must be called to make its - decision. The rule system will know it by looking up the - target list and will suppress the additional query completely - if the attribute isn't touched. So the rule, qualified or not, - will only do its scans if there ever could be something to do. - -]]> - The summary is, rules will only be significantly slower than triggers if their actions result in large and badly qualified