From: Bruce Momjian Date: Fri, 6 May 2005 18:23:13 +0000 (+0000) Subject: Update backend flowchard wording X-Git-Tag: REL8_1_0BETA1~856 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8903592b107a4e911b3c6e2a8227c5c6fc10f7eb;p=postgresql Update backend flowchard wording --- diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index 6d85edfcf8..4ca4969249 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -1,162 +1,167 @@ - - -How PostgreSQL Processes a Query - - -

-How PostgreSQL Processes a Query -

-

-by Bruce Momjian -

-

-flowchart - -main -postmaster -libpq -tcop -tcop -parser -tcop -optimizer -plan -executor -commands -utils -catalog -storage -access -nodes -bootstrap - - -Click on an item to see more detail or look at the full -index. - -
-
-

-

- -A query comes to the backend via data packets arriving through TCP/IP or -Unix Domain sockets. It is loaded into a string, and passed to the -parser, where the lexical scanner, -scan.l, breaks the query up -into tokens(words). The parser uses gram.y and the tokens to identify -the query type, and load the proper query-specific structure, like CreateStmt or SelectStmt.

- - -The query is then identified as a Utility query or a more complex -query. A Utility query is processed by a query-specific function -in commands. A complex query, like -SELECT, UPDATE, and DELETE requires much more handling.

- - -The parser takes a complex query, and creates a -Query structure that -contains all the elements used by complex queries. Query.qual holds the -WHERE clause qualification, which is filled in by transformWhereClause(). -Each table referenced in the query is represented by a RangeTableEntry, and they -are linked together to form the range table of the query, which -is generated by -transformFromClause(). Query.rtable holds the query's range table.

- - -Certain queries, like SELECT, return columns of data. Other -queries, like INSERT and UPDATE, specify the columns -modified by the query. These column references are converted to TargetEntry entries, which are -linked together to make up the target list of -the query. The target list is stored in Query.targetList, which is -generated by transformTargetList().

- - -Other query elements, like aggregates(SUM()), GROUP BY, -and ORDER BY are also stored in their own Query fields.

- - -The next step is for the Query to be modified by any VIEWS or -RULES that may apply to the query. This is performed by the rewrite system.

- - -The optimizer takes the Query -structure and generates an optimal Plan, which contains the -operations to be performed to execute the query. The path module determines the best -table join order and join type of each table in the RangeTable, using -Query.qual(WHERE clause) to consider optimal index usage.

- - -The Plan is then passed to the executor for execution, and the result -returned to the client. The Plan actually as set of nodes, arranged in -a tree structure with a top-level node, and various sub-nodes as -children.

- -There are many other modules that support this basic functionality. They -can be accessed by clicking on the flowchart.

- - -

- - -Another area of interest is the shared memory area, which contains data -accessable to all backends. It has recently used data/index blocks, -locks, backend process information, and lookup tables for these -structures: -

- - - -

Each data structure is created by calling ShmemInitStruct(), and the -lookups are created by ShmemInitHash().

- - -
- -Maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
-Last updated: Mon Aug 10 10:48:06 EDT 1998 - - - + + + + +How PostgreSQL Processes a Query + + +

How PostgreSQL Processes a Query

+ +

by Bruce Momjian

+ +

flowchart + +Click on an item to see more detail or look at the full +index. + + +main +postmaster +libpq +tcop +tcop +parser +tcop +optimizer +plan +executor +commands +utils +catalog +storage +access +nodes +bootstrap + + +
+ +

A query comes to the backend via data packets arriving through +TCP/IP or Unix Domain sockets. It is loaded into a string, and +passed to the parser, where the +lexical scanner, scan.l, +breaks the query up into tokens(words). The parser uses gram.y and the tokens to +identify the query type, and load the proper query-specific +structure, like CreateStmt or SelectStmt.

+ +

The statement is then identified as complex (SELECT / INSERT / +UPDATE / DELETE) or a simple, e.g CREATE USER, ANALYZE, , +etc. Utility commands are processed by statement-specific functions in backend/commands. Complex statements +require more handling.

+ +

The parser takes a complex query, and creates a Query structure that +contains all the elements used by complex queries. Query.qual holds +the WHERE clause qualification, which is filled in by transformWhereClause(). +Each table referenced in the query is represented by a RangeTableEntry, and +they are linked together to form the range table of the +query, which is generated by transformFromClause(). +Query.rtable holds the query's range table.

+ +

Certain queries, like SELECT, return columns of data. +Other queries, like INSERT and UPDATE, specify the +columns modified by the query. These column references are +converted to TargetEntry entries, +which are linked together to make up the target list of the +query. The target list is stored in Query.targetList, which is +generated by transformTargetList().

+ +

Other query elements, like aggregates(SUM()), GROUP +BY, and ORDER BY are also stored in their own Query +fields.

+ +

The next step is for the Query to be modified by any +VIEWS or RULES that may apply to the query. This is +performed by the rewrite +system.

+ +

The optimizer takes the +Query structure and generates an optimal Plan, which contains the +operations to be performed to execute the query. The path module determines the +best table join order and join type of each table in the +RangeTable, using Query.qual(WHERE clause) to consider +optimal index usage.

+ +

The Plan is then passed to the executor for execution, and the +result returned to the client. The Plan actually as set of nodes, +arranged in a tree structure with a top-level node, and various +sub-nodes as children.

+ +

There are many other modules that support this basic +functionality. They can be accessed by clicking on the +flowchart.

+ +
+

Another area of interest is the shared memory area, which +contains data accessable to all backends. It has recently used +data/index blocks, locks, backend process information, and lookup +tables for these structures:

+ + + +

Each data structure is created by calling ShmemInitStruct(), and +the lookups are created by ShmemInitHash().

+ +
+Maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
+ +Last updated: Fri May 6 14:22:27 EDT 2005 + +