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

   1
   2 39.1. The Query Tree #
   3
   4    To understand how the rule system works it is necessary to know when it
   5    is invoked and what its input and results are.
   6
   7    The rule system is located between the parser and the planner. It takes
   8    the output of the parser, one query tree, and the user-defined rewrite
   9    rules, which are also query trees with some extra information, and
  10    creates zero or more query trees as result. So its input and output are
  11    always things the parser itself could have produced and thus, anything
  12    it sees is basically representable as an SQL statement.
  13
  14    Now what is a query tree? It is an internal representation of an SQL
  15    statement where the single parts that it is built from are stored
  16    separately. These query trees can be shown in the server log if you set
  17    the configuration parameters debug_print_parse, debug_print_rewritten,
  18    or debug_print_plan. The rule actions are also stored as query trees,
  19    in the system catalog pg_rewrite. They are not formatted like the log
  20    output, but they contain exactly the same information.
  21
  22    Reading a raw query tree requires some experience. But since SQL
  23    representations of query trees are sufficient to understand the rule
  24    system, this chapter will not teach how to read them.
  25
  26    When reading the SQL representations of the query trees in this chapter
  27    it is necessary to be able to identify the parts the statement is
  28    broken into when it is in the query tree structure. The parts of a
  29    query tree are
  30
  31    the command type
  32           This is a simple value telling which command (SELECT, INSERT,
  33           UPDATE, DELETE) produced the query tree.
  34
  35    the range table
  36           The range table is a list of relations that are used in the
  37           query. In a SELECT statement these are the relations given after
  38           the FROM key word.
  39
  40           Every range table entry identifies a table or view and tells by
  41           which name it is called in the other parts of the query. In the
  42           query tree, the range table entries are referenced by number
  43           rather than by name, so here it doesn't matter if there are
  44           duplicate names as it would in an SQL statement. This can happen
  45           after the range tables of rules have been merged in. The
  46           examples in this chapter will not have this situation.
  47
  48    the result relation
  49           This is an index into the range table that identifies the
  50           relation where the results of the query go.
  51
  52           SELECT queries don't have a result relation. (The special case
  53           of SELECT INTO is mostly identical to CREATE TABLE followed by
  54           INSERT ... SELECT, and is not discussed separately here.)
  55
  56           For INSERT, UPDATE, and DELETE commands, the result relation is
  57           the table (or view!) where the changes are to take effect.
  58
  59    the target list
  60           The target list is a list of expressions that define the result
  61           of the query. In the case of a SELECT, these expressions are the
  62           ones that build the final output of the query. They correspond
  63           to the expressions between the key words SELECT and FROM. (* is
  64           just an abbreviation for all the column names of a relation. It
  65           is expanded by the parser into the individual columns, so the
  66           rule system never sees it.)
  67
  68           DELETE commands don't need a normal target list because they
  69           don't produce any result. Instead, the planner adds a special
  70           CTID entry to the empty target list, to allow the executor to
  71           find the row to be deleted. (CTID is added when the result
  72           relation is an ordinary table. If it is a view, a whole-row
  73           variable is added instead, by the rule system, as described in
  74           Section 39.2.4.)
  75
  76           For INSERT commands, the target list describes the new rows that
  77           should go into the result relation. It consists of the
  78           expressions in the VALUES clause or the ones from the SELECT
  79           clause in INSERT ... SELECT. The first step of the rewrite
  80           process adds target list entries for any columns that were not
  81           assigned to by the original command but have defaults. Any
  82           remaining columns (with neither a given value nor a default)
  83           will be filled in by the planner with a constant null
  84           expression.
  85
  86           For UPDATE commands, the target list describes the new rows that
  87           should replace the old ones. In the rule system, it contains
  88           just the expressions from the SET column = expression part of
  89           the command. The planner will handle missing columns by
  90           inserting expressions that copy the values from the old row into
  91           the new one. Just as for DELETE, a CTID or whole-row variable is
  92           added so that the executor can identify the old row to be
  93           updated.
  94
  95           Every entry in the target list contains an expression that can
  96           be a constant value, a variable pointing to a column of one of
  97           the relations in the range table, a parameter, or an expression
  98           tree made of function calls, constants, variables, operators,
  99           etc.
 100
 101    the qualification
 102           The query's qualification is an expression much like one of
 103           those contained in the target list entries. The result value of
 104           this expression is a Boolean that tells whether the operation
 105           (INSERT, UPDATE, DELETE, or SELECT) for the final result row
 106           should be executed or not. It corresponds to the WHERE clause of
 107           an SQL statement.
 108
 109    the join tree
 110           The query's join tree shows the structure of the FROM clause.
 111           For a simple query like SELECT ... FROM a, b, c, the join tree
 112           is just a list of the FROM items, because we are allowed to join
 113           them in any order. But when JOIN expressions, particularly outer
 114           joins, are used, we have to join in the order shown by the
 115           joins. In that case, the join tree shows the structure of the
 116           JOIN expressions. The restrictions associated with particular
 117           JOIN clauses (from ON or USING expressions) are stored as
 118           qualification expressions attached to those join-tree nodes. It
 119           turns out to be convenient to store the top-level WHERE
 120           expression as a qualification attached to the top-level
 121           join-tree item, too. So really the join tree represents both the
 122           FROM and WHERE clauses of a SELECT.
 123
 124    the others
 125           The other parts of the query tree like the ORDER BY clause
 126           aren't of interest here. The rule system substitutes some
 127           entries there while applying rules, but that doesn't have much
 128           to do with the fundamentals of the rule system.