diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-13 13:44:03 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-13 13:44:03 +0000 |
| commit | 293913568e6a7a86fd1479e1cff8e2ecb58d6568 (patch) | |
| tree | fc3b469a3ec5ab71b36ea97cc7aaddb838423a0c /doc/src/sgml/html/querytree.html | |
| parent | Initial commit. (diff) | |
| download | postgresql-16-293913568e6a7a86fd1479e1cff8e2ecb58d6568.tar.xz postgresql-16-293913568e6a7a86fd1479e1cff8e2ecb58d6568.zip | |
Adding upstream version 16.2.upstream/16.2
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/src/sgml/html/querytree.html')
| -rw-r--r-- | doc/src/sgml/html/querytree.html | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/doc/src/sgml/html/querytree.html b/doc/src/sgml/html/querytree.html new file mode 100644 index 0000000..d9b28dc --- /dev/null +++ b/doc/src/sgml/html/querytree.html @@ -0,0 +1,152 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>41.1. The Query Tree</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="rules.html" title="Chapter 41. The Rule System" /><link rel="next" href="rules-views.html" title="41.2. Views and the Rule System" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">41.1. The Query Tree</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="rules.html" title="Chapter 41. The Rule System">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="rules.html" title="Chapter 41. The Rule System">Up</a></td><th width="60%" align="center">Chapter 41. The Rule System</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.2 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="rules-views.html" title="41.2. Views and the Rule System">Next</a></td></tr></table><hr /></div><div class="sect1" id="QUERYTREE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">41.1. The Query Tree <a href="#QUERYTREE" class="id_link">#</a></h2></div></div></div><a id="id-1.8.6.6.2" class="indexterm"></a><p> + To understand how the rule system works it is necessary to know + when it is invoked and what its input and results are. +</p><p> + The rule system is located between the parser and the planner. + It takes the output of the parser, one query tree, and the user-defined + rewrite rules, which are also + query trees with some extra information, and creates zero or more + query trees as result. So its input and output are always things + the parser itself could have produced and thus, anything it sees + is basically representable as an <acronym class="acronym">SQL</acronym> statement. +</p><p> + Now what is a query tree? It is an internal representation of an + <acronym class="acronym">SQL</acronym> statement where the single parts that it is + built from are stored separately. These query trees can be shown + in the server log if you set the configuration parameters + <code class="varname">debug_print_parse</code>, + <code class="varname">debug_print_rewritten</code>, or + <code class="varname">debug_print_plan</code>. The rule actions are also + stored as query trees, in the system catalog + <code class="structname">pg_rewrite</code>. They are not formatted like + the log output, but they contain exactly the same information. +</p><p> + Reading a raw query tree requires some experience. But since + <acronym class="acronym">SQL</acronym> representations of query trees are + sufficient to understand the rule system, this chapter will not + teach how to read them. +</p><p> + When reading the <acronym class="acronym">SQL</acronym> representations of the + query trees in this chapter it is necessary to be able to identify + the parts the statement is broken into when it is in the query tree + structure. The parts of a query tree are + +</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"> + the command type + </span></dt><dd><p> + This is a simple value telling which command + (<code class="command">SELECT</code>, <code class="command">INSERT</code>, + <code class="command">UPDATE</code>, <code class="command">DELETE</code>) produced + the query tree. + </p></dd><dt><span class="term"> + the range table + <a id="id-1.8.6.6.7.2.2.1.1" class="indexterm"></a> + </span></dt><dd><p> + The range table is a list of relations that are used in the query. + In a <code class="command">SELECT</code> statement these are the relations given after + the <code class="literal">FROM</code> key word. + </p><p> + Every range table entry identifies a table or view and tells + by which name it is called in the other parts of the query. + In the query tree, the range table entries are referenced by + number rather than by name, so here it doesn't matter if there + are duplicate names as it would in an <acronym class="acronym">SQL</acronym> + statement. This can happen after the range tables of rules + have been merged in. The examples in this chapter will not have + this situation. + </p></dd><dt><span class="term"> + the result relation + </span></dt><dd><p> + This is an index into the range table that identifies the + relation where the results of the query go. + </p><p> + <code class="command">SELECT</code> queries don't have a result + relation. (The special case of <code class="command">SELECT INTO</code> is + mostly identical to <code class="command">CREATE TABLE</code> followed by + <code class="literal">INSERT ... SELECT</code>, and is not discussed + separately here.) + </p><p> + For <code class="command">INSERT</code>, <code class="command">UPDATE</code>, and + <code class="command">DELETE</code> commands, the result relation is the table + (or view!) where the changes are to take effect. + </p></dd><dt><span class="term"> + the target list + <a id="id-1.8.6.6.7.2.4.1.1" class="indexterm"></a> + </span></dt><dd><p> + The target list is a list of expressions that define the + result of the query. In the case of a + <code class="command">SELECT</code>, these expressions are the ones that + build the final output of the query. They correspond to the + expressions between the key words <code class="command">SELECT</code> + and <code class="command">FROM</code>. (<code class="literal">*</code> is just an + abbreviation for all the column names of a relation. It is + expanded by the parser into the individual columns, so the + rule system never sees it.) + </p><p> + <code class="command">DELETE</code> commands don't need a normal target list + because they don't produce any result. Instead, the planner + adds a special <acronym class="acronym">CTID</acronym> entry to the empty target list, + to allow the executor to find the row to be deleted. + (<acronym class="acronym">CTID</acronym> is added when the result relation is an ordinary + table. If it is a view, a whole-row variable is added instead, by + the rule system, as described in <a class="xref" href="rules-views.html#RULES-VIEWS-UPDATE" title="41.2.4. Updating a View">Section 41.2.4</a>.) + </p><p> + For <code class="command">INSERT</code> commands, the target list describes + the new rows that should go into the result relation. It consists of the + expressions in the <code class="literal">VALUES</code> clause or the ones from the + <code class="command">SELECT</code> clause in <code class="literal">INSERT + ... SELECT</code>. The first step of the rewrite process adds + target list entries for any columns that were not assigned to by + the original command but have defaults. Any remaining columns (with + neither a given value nor a default) will be filled in by the + planner with a constant null expression. + </p><p> + For <code class="command">UPDATE</code> commands, the target list + describes the new rows that should replace the old ones. In the + rule system, it contains just the expressions from the <code class="literal">SET + column = expression</code> part of the command. The planner will + handle missing columns by inserting expressions that copy the values + from the old row into the new one. Just as for <code class="command">DELETE</code>, + a <acronym class="acronym">CTID</acronym> or whole-row variable is added so that + the executor can identify the old row to be updated. + </p><p> + Every entry in the target list contains an expression that can + be a constant value, a variable pointing to a column of one + of the relations in the range table, a parameter, or an expression + tree made of function calls, constants, variables, operators, etc. + </p></dd><dt><span class="term"> + the qualification + </span></dt><dd><p> + The query's qualification is an expression much like one of + those contained in the target list entries. The result value of + this expression is a Boolean that tells whether the operation + (<code class="command">INSERT</code>, <code class="command">UPDATE</code>, + <code class="command">DELETE</code>, or <code class="command">SELECT</code>) for the + final result row should be executed or not. It corresponds to the <code class="literal">WHERE</code> clause + of an <acronym class="acronym">SQL</acronym> statement. + </p></dd><dt><span class="term"> + the join tree + </span></dt><dd><p> + The query's join tree shows the structure of the <code class="literal">FROM</code> clause. + For a simple query like <code class="literal">SELECT ... FROM a, b, c</code>, the join tree is just + a list of the <code class="literal">FROM</code> items, because we are allowed to join them in + any order. But when <code class="literal">JOIN</code> expressions, particularly outer joins, + are used, we have to join in the order shown by the joins. + In that case, the join tree shows the structure of the <code class="literal">JOIN</code> expressions. The + restrictions associated with particular <code class="literal">JOIN</code> clauses (from <code class="literal">ON</code> or + <code class="literal">USING</code> expressions) are stored as qualification expressions attached + to those join-tree nodes. It turns out to be convenient to store + the top-level <code class="literal">WHERE</code> expression as a qualification attached to the + top-level join-tree item, too. So really the join tree represents + both the <code class="literal">FROM</code> and <code class="literal">WHERE</code> clauses of a <code class="command">SELECT</code>. + </p></dd><dt><span class="term"> + the others + </span></dt><dd><p> + The other parts of the query tree like the <code class="literal">ORDER BY</code> + clause aren't of interest here. The rule system + substitutes some entries there while applying rules, but that + doesn't have much to do with the fundamentals of the rule + system. + </p></dd></dl></div><p> +</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="rules.html" title="Chapter 41. The Rule System">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="rules.html" title="Chapter 41. The Rule System">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="rules-views.html" title="41.2. Views and the Rule System">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 41. The Rule System </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.2 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 41.2. Views and the Rule System</td></tr></table></div></body></html>
\ No newline at end of file |