From b15e7df8c943225e1ae09ec500af9bcc21f6b779 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 28 Jun 1998 16:35:41 +0000 Subject: [PATCH] backend update. --- src/tools/backend/index.html | 91 +++++++++++++++++------------------- 1 file changed, 44 insertions(+), 47 deletions(-) diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index dbf78042a4..7fe6440431 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -8,30 +8,30 @@ PostgreSQL Backend Flowchart

by Bruce Momjian -

+

-Queries come into the backend via data packets coming in through TCP/IP -and Unix Domain sockets. They are loaded into a string, and passed to +A query come into the backend via data packets coming in through TCP/IP +and 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-type-specific +identify the query type, and load the proper query-specific structure, like CreateStmt or SelectStmt.

The query is then identified as a Utility function or a more -complex query. Utility queries are processed by a -query-type-specific function in -commands. Complex queries, like SELECT, UPDATE, and -DELETE require much more handling. +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 the complex queries, and creates a +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 +WHERE clause qualification, which is filled in by transformWhereClause(). Each table referenced in the query is represented by a RangeTableEntry, and they @@ -39,73 +39,70 @@ are linked together to form the range table of the query, which is generated by makeRangeTable(). Query.rtable holds the queries 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 Resdom entries, which are +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 Resdom 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, ORDER BY are -also stored in their own Query fields. +Other query elements, like aggregates(SUM()), GROUP BY, +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 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 containing the -primitive operations to be performed by the executor 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. +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 -is returned to the client. +returned to the client.

-There are many other modules that support this basic functionality. +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, containing table data/index blocks, locks, and backend information:

Each data structure is created by calling ShmemInitStruct(), and -the lookup hashes are created by +HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and +the lookups are created by ShmemInitHash().
-Click on an item to see more detail or click -here to see the full index. - +Click on an item to see more detail or +click to see the full index. +

- +flowchart
-- 2.40.0