Update.
authorBruce Momjian
Tue, 21 Jul 1998 04:48:31 +0000 (04:48 +0000)
committerBruce Momjian
Tue, 21 Jul 1998 04:48:31 +0000 (04:48 +0000)
src/tools/backend/index.html

index 51e4972037f4dff6974512824c27b0d605d935b9..300061deae1e37a8755af239c62565758d429e3c 100644 (file)
@@ -43,37 +43,35 @@ Click on an item to see more detail or look at the full
 
 
 

-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
+
+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 
-HREF="../../include/nodes/parsenodes.h">SelectStmt.
-

+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.
-

+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().
+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 
-makeRangeTable().  Query.rtable holds the query's range table.
-

+are linked together to form the range table of the query, which
+is generated by 
+makeRangeTable().  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
@@ -82,18 +80,18 @@ HREF="../../include/nodes/primnodes.h">Resdom entries, which are
 placed in target list
 entries, and linked together to make up the target list of
 the query. The target list is stored in Query.targetList, which is
-generated by
-transformTargetList().>
-

+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.
-

+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.
-

+HREF="../../backend/rewrite">rewrite system.

+
 
 The optimizer takes the Query
 structure and generates an optimal 
@@ -101,45 +99,46 @@ 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.
-

+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.
-

+children.

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

 
-
-

+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 table recently used data/index
 blocks, locks, backend 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(
    -BufferTag)
    -
  • MultiLevelLockTable (ctl) - control structure for
  • -each locking method.  Currently, only multi-level locking is used(
    +
  • 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/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
  • @@ -152,11 +151,12 @@ 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
    -ShmemInitHash().>
    -

    +HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and the
    +lookups are created by 
    +HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().>
    +