Update backend flowchart.

src/backend/storage/ipc/shmem.c

@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.25 1998/06/27 15:47:44 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.26 1998/06/28 06:17:13 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */

src/tools/backend/index.html

@@ -9,8 +9,90 @@ PostgreSQL Backend Flowchart
 <H2 ALIGN=CENTER>
 by Bruce Momjian
 </H2 ALIGN=CENTER>
+<P>
+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
+<A HREF="../../backend/parser">parser,</A> where the lexical scanner,
+<A HREF="../../backend/parser/scan.l">scan.l,</A>
+breaks the query up into tokens(words).  The parser
+uses
+<A HREF="../../backend/parser/gram.y">gram.y</A> and the tokens to
+identify the query type, and load the proper query-type-specific
+structure, like
+<A HREF="../../include/nodes/parsenodes.h">CreateStmt or SelectStmt.</A>
+<P>
+The query is then identified as a <I>Utility</I> function or a more
+complex query.  <I>Utility</I> queries are processed by a
+query-type-specific function in <A HREF="../../backend/commands">
+commands.</A> Complex queries, like <I>SELECT, UPDATE,</I> and
+<I>DELETE</I> require much more handling.  
+<P>
+The parser takes the complex queries, and creates a
+<A HREF="../../include/nodes/parsenodes.h">Query</A> structure that
+contains all the elements used by complex queries.  Query.qual holds the
+WHERE clause qualification, which is filled in by
+
+<A HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A>
+Each table is represented by a <A HREF="../../include/nodes/parsenodes.h">
+RangeTableEntry,</A>
+and they are linked together to form the <I>range table</I> for the
+query, and is generated by <A HREF="../../backend/parser/parse_clause.c">
+makeRangeTable().</A>  Query.rtable holds the queries range table.
+<P>
+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 <A
+HREF="../../include/nodes/primnodes.h"> Resdom</A> entries, which are
+linked together to make up the <I>target list</I> of the query. The
+target list is stored in Query.targetList, and is generated by
+<A HREF="../../backend/parser/parse_target.c">transformTargetList().</A>
+<P>
+Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are
+also stored in their own fields.
+<P>
+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 <A
+HREF="../../backend/rewrite">rewrite</A> system.
+<P>
+The optimizer takes the Query structure, and generates an optimal
+<A HREF="../..//include/nodes/plannodes.h">Plan</A> containing primitive
+operations to be performed by the executor to complete the query.  The
+<A HREF="../../backend/optimizer/path">path</A> 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.
+<P>
+The Plan is then passed to the <A
+HREF="../../backend/executor">executor</A> for execution, and the result
+is returned to the client.
+<P>
+There are many other modules that support this basic functionality. 
+They can be accessed by clicking on the flowchart.
+<P>
+Another area of interest is the shared memory area, containing
+table data/index blocks, locks, and backend information:
+<UL> 
+<LI>ShmemIndex - contains an index of all other shared memory
+structures, allowing quick lookup of other structure locations in shared
+memory
+<LI>Buffer Descriptors - control header for shared memory buffer block
+<LI>Buffer Blocks - block of table/index data shared by all backends
+<LI>Shared Buf Lookup Table - lookup to see if a requested buffer
+is already in the shared memory area
+<LI>LockTable - lock table structure, specifiying table, lock types, and
+backends holding or waiting on lock
+<LI>LockTable (lock hash) - lookup of LockTable structures using
+table name
+<LI>LockTable (xid hash) - lookup of LockTable structures using
+transaction id
+<LI>Proc Header - information about each backend, including locks held/waiting, 
+indexed by process id
+</UL>
+Each structure is created by calling <A
+HREF="../../backend/storage/ipc/shmem.c"> ShmemInitStruct().</A>
+<HR>
 <CENTER>
-<BR>
 <EM><BIG>
 Click on an item to see more detail or click
 <A HREF="backend_dirs.html">here</a> to see the full index.
@@ -38,9 +120,14 @@ Click on an item to see more detail or click
 <AREA COORDS="10,510,170,550" HREF="backend_dirs.html#nodes">
 <AREA COORDS="10,570,170,610" HREF="backend_dirs.html#storage">
 </MAP>
-<HR>
+<BR>
+<HR SIZE="2" NOSHADE>
+<SMALL>
 <ADDRESS>
-Maintainer:	Bruce Momjian<A
-HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</a>)<BR>
-Last updated:		Mon Oct 27 11:01:08 EST 1997
+Maintainer:	Bruce Momjian (<A
+HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</A>)<BR>
+Last updated:		Tue Dec  9 17:56:08 EST 1997
 </ADDRESS>
+</SMALL>
+</BODY>
+</HTML>