@@ -2434,30 +2434,6 @@ Nestloop
2434
2434
in a command.
2435
2435
</para>
2436
2436
2437
- <!-- What's happening with this? If it doesn't come back, remove this section. -->
2438
- <!--
2439
- <para>
2440
- Another situation is cases on <command>UPDATE</command> where it depends on the
2441
- change of an attribute if an action should be performed or
2442
- not. The only way to
2443
- create a rule as in the shoelace_log example is to do it with
2444
- a rule qualification. That results in an extra query that is
2445
- performed always, even if the attribute of interest cannot
2446
- change at all because it does not appear in the target list
2447
- of the initial query. When this is enabled again, it will be
2448
- one more advantage of rules over triggers. Optimization of
2449
- a trigger must fail by definition in this case, because the
2450
- fact that its actions will only be done when a specific attribute
2451
- is updated is hidden in its functionality. The definition of
2452
- a trigger only allows to specify it on row level, so whenever a
2453
- row is touched, the trigger must be called to make its
2454
- decision. The rule system will know it by looking up the
2455
- target list and will suppress the additional query completely
2456
- if the attribute isn't touched. So the rule, qualified or not,
2457
- will only do its scans if there ever could be something to do.
2458
- </para>
2459
- -->
2460
-
2461
2437
<para>
2462
2438
The summary is, rules will only be significantly slower than
2463
2439
triggers if their actions result in large and badly qualified
0 commit comments