On Thu, Apr 16, 2020 at 11:17:29AM -0400, Alvaro Herrera wrote: > On 2020-Apr-15, Marc Rechté wrote: > > > Hello, > > > > Don't know if this the correct list to submit this issue. > > > > On the https://www.postgresql.org/developer/backend/, it mentions a > > Query.qual field which does not exist in the Query structure. > > I think that diagram (and the accompanying wiki page) requires a *lot* > of more significant updating than just that field. It is wildly > outdated.
I developed the attached patch to fix the items I saw needed updating. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
diff --git a/templates/pages/developer/backend.html b/templates/pages/developer/backend.html index ab7e5d6..7337a07 100644 --- a/templates/pages/developer/backend.html +++ b/templates/pages/developer/backend.html @@ -56,7 +56,7 @@ or <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">SelectStmt.</a></p> <p>The statement is then identified as complex (<em>SELECT / INSERT / -UPDATE / DELETE</em>) or simple, e.g <em>CREATE USER, ANALYZE,</em> +UPDATE / DELETE</em>) or simple, e.g <em>CREATE ROLE, ANALYZE,</em> etc. Simple utility commands that do not require the executor are processed by statement-specific functions in the <a href="https://wiki.postgresql.org/wiki/Backend_flowchart#commands">commands</a> module. Complex statements require more handling.</p> @@ -64,11 +64,12 @@ Complex statements require more handling.</p> <p>The parser takes a complex query, and creates a <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">Query</a> structure that contains all the elements used by complex queries. -Query.qual holds the <em>WHERE</em> clause qualification, which is filled +Query.jointree holds the <em>FROM</em> and <em>WHERE</em> clauses, which is filled in by <a +href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c">transformFromClause()</a> and href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c">transformWhereClause().</a> Each table referenced in the query is represented by a <a -href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">RangeTableEntry,</a> +href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">RangeTblEntry,</a> and they are linked together to form the <em>range table</em> of the query, which is generated by <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c">transformFromClause().</a> @@ -95,8 +96,8 @@ system.</p> <p>The <a href="https://wiki.postgresql.org/wiki/Backend_flowchart#optimizer_path">optimizer</a> uses the Query structure to determine the best table join order and join -type of each table in the RangeTable, using Query.qual(<em>WHERE</em> -clause) to consider optimal index usage.</p> The <a +type of each table in the RangeTable, using Query.jointree(<em>FROM</em> +and <em>WHERE</em> clauses) to consider optimal index usage.</p> The <a href="https://wiki.postgresql.org/wiki/Backend_flowchart#optimizer_path">path</a> module then generates an optimal <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/plannodes.h">Plan,</a>