From 0cba5523013ee058aa901b3d1013ca7a0a8e2bb9 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 28 Jun 1998 06:17:14 +0000 Subject: Update backend flowchart. --- src/tools/backend/index.html | 97 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 92 insertions(+), 5 deletions(-) (limited to 'src/tools/backend/index.html') diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index 04166222afb..e286b6d8c66 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -9,8 +9,90 @@ 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 +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 +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. +

+The parser takes the complex queries, 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 is represented by a +RangeTableEntry, +and they are linked together to form the range table for the +query, and 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 columns 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, and is generated by +transformTargetList(). +

+Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are +also stored in their own 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 containing primitive +operations to be performed by the executor to complete the query. The +path module +determines the table join order and join type of each of the tables 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. +

+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 structure is created by calling ShmemInitStruct(). +
-
Click on an item to see more detail or click here to see the full index. @@ -38,9 +120,14 @@ Click on an item to see more detail or click -
+
+
+
-Maintainer: Bruce Momjianmaillist@candle.pha.pa.us)
-Last updated: Mon Oct 27 11:01:08 EST 1997 +Maintainer: Bruce Momjian (maillist@candle.pha.pa.us)
+Last updated: Tue Dec 9 17:56:08 EST 1997
+ + + -- cgit v1.2.3