Update backend flowchard wording

diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html
index 6d85edfcf84a8fc181a8612f06cb0e6bdd53d1e0..4ca496924900e9235091bb70ab0770d87293f206 100644 (file)
--- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 
-HREF="../../backend/parser/gram.y">gram.y and the tokens to identify
-the query type, and load the proper query-specific structure, like 
-HREF="../../include/nodes/parsenodes.h">CreateStmt or 
-HREF="../../include/nodes/parsenodes.h">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 
-HREF="../../backend/parser/parse_clause.c">transformWhereClause().
-Each table referenced in the query is represented by a 
-HREF="../../include/nodes/parsenodes.h"> 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 
-HREF="../../include/nodes/primnodes.h">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 
-HREF="../../backend/parser/parse_target.c">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 
-HREF="../../backend/rewrite">rewrite system.
-
-
-The optimizer takes the Query
-structure and generates an optimal 
-HREF="../../include/nodes/plannodes.h">Plan, which contains the
-operations to be performed to execute the query.  The 
-HREF="../../backend/optimizer/path">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 
-HREF="../../backend/executor">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:
-
-
- 
-ShmemIndex - lookup shared memory addresses using structure names
-Buffer
-Descriptor - control header for buffer cache block
-Buffer Block -
-data/index buffer cache block
-Shared Buffer Lookup Table - lookup of buffer cache block addresses
-using table name and block number(
-HREF="../../include/storage/buf_internals.h"> BufferTag)
-MultiLevelLockTable (ctl) - control structure for each locking
-method.  Currently, only multi-level locking is used(
-HREF="../../include/storage/lock.h">LOCKMETHODCTL).
-MultiLevelLockTable (lock hash) - the 
-HREF="../../include/storage/lock.h">LOCK structure, looked up using
-relation, database object ids(
-HREF="../../include/storage/lock.h">LOCKTAG).  The lock table
-structure contains the lock modes(read/write or shared/exclusive) and
-circular linked list of backends (
-HREF="../../include/storage/proc.h">PROC structure pointers) waiting
-on the lock.
-MultiLevelLockTable (xid hash) - lookup of LOCK structure address
-using transaction id, LOCK address.  It is used to quickly check if the
-current transaction already has any locks on a table, rather than having
-to search through all the held locks.  It also stores the modes
-(read/write) of the locks held by the current transaction.  The returned
-XIDLookupEnt structure also
-contains a pointer to the backend's PROC.lockQueue.
-Proc Header - information
-about each backend, including locks held/waiting, indexed by process id
-
-
-Each data structure is created by calling 
-HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and the
-lookups are created by 
-HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().
-
-
-
-
-Maintainer:    Bruce Momjian (
-HREF="mailto:[email protected]">[email protected])
-Last updated:      Mon Aug 10 10:48:06 EDT 1998
-
-
-
+
+    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+
+content="HTML Tidy for BSD/OS (vers 1st July 2002), see www.w3.org" />
+How PostgreSQL Processes a Query
+
+
+vlink="#A00000" alink="#0000FF">
+How PostgreSQL Processes a Query
+
+by Bruce Momjian
+
+
+
+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 
+href="../../backend/parser/gram.y">gram.y and the tokens to
+identify the query type, and load the proper query-specific
+structure, like 
+href="../../include/nodes/parsenodes.h">CreateStmt or 
+href="../../include/nodes/parsenodes.h">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 
+href="../../backend/commands">backend/commands. Complex statements
+require more handling.
+
+The parser takes a complex query, and creates a 
+href="../../include/nodes/parsenodes.h">Query structure that
+contains all the elements used by complex queries. Query.qual holds
+the WHERE clause qualification, which is filled in by 
+href="../../backend/parser/parse_clause.c">transformWhereClause().
+Each table referenced in the query is represented by a 
+href="../../include/nodes/parsenodes.h">RangeTableEntry, and
+they are linked together to form the range table of the
+query, which is generated by 
+href="../../backend/parser/parse_clause.c">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 
+href="../../include/nodes/primnodes.h">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 
+href="../../backend/parser/parse_target.c">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 
+href="../../include/nodes/plannodes.h">Plan, which contains the
+operations to be performed to execute the query. The 
+href="../../backend/optimizer/path">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 
+href="../../backend/executor">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:
+
+
+ShmemIndex - lookup shared memory addresses using structure
+names
+
+Buffer
+Descriptor - control header for buffer cache block
+
+Buffer
+Block - data/index buffer cache block
+
+Shared Buffer Lookup Table - lookup of buffer cache block
+addresses using table name and block number( 
+href="../../include/storage/buf_internals.h">BufferTag)
+
+MultiLevelLockTable (ctl) - control structure for each locking
+method. Currently, only multi-level locking is used(
+href="../../include/storage/lock.h">LOCKMETHODCTL).
+
+MultiLevelLockTable (lock hash) - the 
+href="../../include/storage/lock.h">LOCK structure, looked up
+using relation, database object ids(
+href="../../include/storage/lock.h">LOCKTAG). The lock table
+structure contains the lock modes(read/write or shared/exclusive)
+and circular linked list of backends (
+href="../../include/storage/proc.h">PROC structure pointers)
+waiting on the lock.
+
+MultiLevelLockTable (xid hash) - lookup of LOCK structure
+address using transaction id, LOCK address. It is used to quickly
+check if the current transaction already has any locks on a table,
+rather than having to search through all the held locks. It also
+stores the modes (read/write) of the locks held by the current
+transaction. The returned 
+href="../../include/storage/lock.h">XIDLookupEnt structure also
+contains a pointer to the backend's PROC.lockQueue.
+
+Proc Header -
+information about each backend, including locks held/waiting,
+indexed by process id
+
+
+Each data structure is created by calling 
+href="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and
+the lookups are created by 
+href="../../backend/storage/ipc/shmem.c">ShmemInitHash().
+
+
+Maintainer: Bruce Momjian (
+href="mailto:[email protected]">[email protected])
+
+Last updated: Fri May  6 14:22:27 EDT 2005
+
+




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};