begriffs open source - ai-pg/blob - full-docs/txt/rules-triggers.txt

   1
   2 39.7. Rules Versus Triggers #
   3
   4    Many things that can be done using triggers can also be implemented
   5    using the PostgreSQL rule system. One of the things that cannot be
   6    implemented by rules are some kinds of constraints, especially foreign
   7    keys. It is possible to place a qualified rule that rewrites a command
   8    to NOTHING if the value of a column does not appear in another table.
   9    But then the data is silently thrown away and that's not a good idea.
  10    If checks for valid values are required, and in the case of an invalid
  11    value an error message should be generated, it must be done by a
  12    trigger.
  13
  14    In this chapter, we focused on using rules to update views. All of the
  15    update rule examples in this chapter can also be implemented using
  16    INSTEAD OF triggers on the views. Writing such triggers is often easier
  17    than writing rules, particularly if complex logic is required to
  18    perform the update.
  19
  20    For the things that can be implemented by both, which is best depends
  21    on the usage of the database. A trigger is fired once for each affected
  22    row. A rule modifies the query or generates an additional query. So if
  23    many rows are affected in one statement, a rule issuing one extra
  24    command is likely to be faster than a trigger that is called for every
  25    single row and must re-determine what to do many times. However, the
  26    trigger approach is conceptually far simpler than the rule approach,
  27    and is easier for novices to get right.
  28
  29    Here we show an example of how the choice of rules versus triggers
  30    plays out in one situation. There are two tables:
  31 CREATE TABLE computer (
  32     hostname        text,    -- indexed
  33     manufacturer    text     -- indexed
  34 );
  35
  36 CREATE TABLE software (
  37     software        text,    -- indexed
  38     hostname        text     -- indexed
  39 );
  40
  41    Both tables have many thousands of rows and the indexes on hostname are
  42    unique. The rule or trigger should implement a constraint that deletes
  43    rows from software that reference a deleted computer. The trigger would
  44    use this command:
  45 DELETE FROM software WHERE hostname = $1;
  46
  47    Since the trigger is called for each individual row deleted from
  48    computer, it can prepare and save the plan for this command and pass
  49    the hostname value in the parameter. The rule would be written as:
  50 CREATE RULE computer_del AS ON DELETE TO computer
  51     DO DELETE FROM software WHERE hostname = OLD.hostname;
  52
  53    Now we look at different types of deletes. In the case of a:
  54 DELETE FROM computer WHERE hostname = 'mypc.local.net';
  55
  56    the table computer is scanned by index (fast), and the command issued
  57    by the trigger would also use an index scan (also fast). The extra
  58    command from the rule would be:
  59 DELETE FROM software WHERE computer.hostname = 'mypc.local.net'
  60                        AND software.hostname = computer.hostname;
  61
  62    Since there are appropriate indexes set up, the planner will create a
  63    plan of
  64 Nestloop
  65   ->  Index Scan using comp_hostidx on computer
  66   ->  Index Scan using soft_hostidx on software
  67
  68    So there would be not that much difference in speed between the trigger
  69    and the rule implementation.
  70
  71    With the next delete we want to get rid of all the 2000 computers where
  72    the hostname starts with old. There are two possible commands to do
  73    that. One is:
  74 DELETE FROM computer WHERE hostname >= 'old'
  75                        AND hostname <  'ole'
  76
  77    The command added by the rule will be:
  78 DELETE FROM software WHERE computer.hostname >= 'old' AND computer.hostname < 'o
  79 le'
  80                        AND software.hostname = computer.hostname;
  81
  82    with the plan
  83 Hash Join
  84   ->  Seq Scan on software
  85   ->  Hash
  86     ->  Index Scan using comp_hostidx on computer
  87
  88    The other possible command is:
  89 DELETE FROM computer WHERE hostname ~ '^old';
  90
  91    which results in the following executing plan for the command added by
  92    the rule:
  93 Nestloop
  94   ->  Index Scan using comp_hostidx on computer
  95   ->  Index Scan using soft_hostidx on software
  96
  97    This shows, that the planner does not realize that the qualification
  98    for hostname in computer could also be used for an index scan on
  99    software when there are multiple qualification expressions combined
 100    with AND, which is what it does in the regular-expression version of
 101    the command. The trigger will get invoked once for each of the 2000 old
 102    computers that have to be deleted, and that will result in one index
 103    scan over computer and 2000 index scans over software. The rule
 104    implementation will do it with two commands that use indexes. And it
 105    depends on the overall size of the table software whether the rule will
 106    still be faster in the sequential scan situation. 2000 command
 107    executions from the trigger over the SPI manager take some time, even
 108    if all the index blocks will soon be in the cache.
 109
 110    The last command we look at is:
 111 DELETE FROM computer WHERE manufacturer = 'bim';
 112
 113    Again this could result in many rows to be deleted from computer. So
 114    the trigger will again run many commands through the executor. The
 115    command generated by the rule will be:
 116 DELETE FROM software WHERE computer.manufacturer = 'bim'
 117                        AND software.hostname = computer.hostname;
 118
 119    The plan for that command will again be the nested loop over two index
 120    scans, only using a different index on computer:
 121 Nestloop
 122   ->  Index Scan using comp_manufidx on computer
 123   ->  Index Scan using soft_hostidx on software
 124
 125    In any of these cases, the extra commands from the rule system will be
 126    more or less independent from the number of affected rows in a command.
 127
 128    The summary is, rules will only be significantly slower than triggers
 129    if their actions result in large and badly qualified joins, a situation
 130    where the planner fails.