Update backend flowchart.

diff --git a/src/backend/storage/ipc/shmem.c b/src/backend/storage/ipc/shmem.c
index 0a29a19c0f279daf1106737c46600dea361e91a6..247a2bc62aea1f475ea66a30a08cf6e14fa7328b 100644 (file)
--- a/src/backend/storage/ipc/shmem.c
+++ b/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 $
  *
  *-------------------------------------------------------------------------
  */
@@ -487,7 +487,7 @@ ShmemInitStruct(char *name, unsigned long size, bool *foundPtr)
    item.location = BAD_LOCATION;
 
    SpinAcquire(ShmemIndexLock);
-
+   
    if (!ShmemIndex)
    {
 #ifdef USE_ASSERT_CHECKING

diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html
index c5bd3a52fe2919236bc4be0e36dae453f9ad7aed..63b4a3421aa0b10ce66a3afc0413606a47d909b7 100644 (file)
--- a/src/tools/backend/backend_dirs.html
+++ b/src/tools/backend/backend_dirs.html
@@ -8,15 +8,16 @@ PostgreSQL Backend Directories
 
 
 by Bruce Momjian
- ALIGN=CENTER>
+
 
 
+
 Click on any of the section headings to see the source code for that section.
 
 
 
-
-bootstrap
+
+bootstrap
 - creates initial template database via initdb
 
 
@@ -29,8 +30,8 @@ This code jams the data directly into tables using a
 special syntax used only by the bootstrap procedure.
 
 
-
-main
+
+main
 - passes control to postmaster or postgres
 
 
@@ -38,8 +39,8 @@ This checks the process name(argv[0]) and various flags, and passes
 control to the postmaster or postgres backend code.
 
 
-
-postmaster
+
+postmaster
 - controls postgres server startup/termination
 
 
@@ -49,16 +50,16 @@ When a connection request arrives, a postgres backend is started,
 and the connection is passed to it.
 
 
-
-libpq
+
+libpq
 - backend libpq library routines
 
 
 This handles communication to the client processes.
 
 
-
-tcop
+
+tcop
 - traffic cop, dispatches request to proper module
 
 
@@ -67,8 +68,8 @@ code that makes calls to the parser, optimizer, executor, and
 /commands functions.
 
 
-
-parser
+
+parser
 - converts SQL query to query tree
 
 
@@ -84,19 +85,19 @@ The command-specific structures are then broken apart, checked, and passed to
 Nodes to be handled by the optimizer and executor.
 
 
-
-optimizer
+
+optimizer
 - creates path and plan
 
 
 This uses the parser output to generate an optimal plan for the
 executor.
 
-4>
-
-optimizer/path
+3>
+
+optimizer/path
 - creates path from parser output
-4>
+3>
 
 This takes the parser query output, and generates all possible methods of
 executing the request.
@@ -104,11 +105,11 @@ It examines table join order, where clause restrictions,
 and optimizer table statistics to evaluate each possible execution
 method, and assigns a cost to each.
 
-4>
-
-optimizer/geqo
+3>
+
+optimizer/geqo
 - genetic query optimizer
-4>
+3>
 
 optimizer/path evaluates all possible ways to join the requested tables.
 When the number of tables becomes great, the number of tests made
@@ -119,34 +120,34 @@ For a few tables, this method takes longer, but for a large number of
 tables, it is faster.
 There is an option to control when this feature is used.
 
-4>
-
-optimizer/plan
+3>
+
+optimizer/plan
 - optimizes path output
-4>
+3>
 
 This takes the optimizer/path output, chooses the path with the
 least cost, and creates a plan for the executor.
 
-4>
-
-optimizer/prep
+3>
+
+optimizer/prep
 - handle special plan cases
-4>
+3>
 
 This does special plan processing.
 
-4>
-
-optimizer/util
+3>
+
+optimizer/util
 - optimizer support routines
-4>
+3>
 
 This contains support routines used by other parts of the optimizer.
 
 
-
-executor
+
+executor
 - executes complex node plans from optimizer
 
 
@@ -156,8 +157,8 @@ heap scans, index scans, sorting, joining tables, grouping, aggregates,
 and uniqueness.
 
 
-
-commands
+
+commands
 - commands that do not require the executor
 
 
@@ -169,8 +170,8 @@ Most of the routines do some processing, then call lower-level functions
 in the catalog directory to do the actual work.
 
 
-
-catalog
+
+catalog
 - system catalog manipulation
 
 
@@ -181,47 +182,47 @@ These are low-level routines, and are usually called by upper routines
 that pre-format user requests into a predefined format.
 
 
-
-storage
+
+storage
 - manages various storage systems
 
 
 These allow uniform resource access by the backend.
 
 
-
-storage/buffer
+
+storage/buffer
 - shared buffer pool manager
 
-
-storage/file
+
+storage/file
 - file manager
 
-
-storage/ipc
+
+storage/ipc
 - semaphores and shared memory
 
-
-storage/large_object
+
+storage/large_object
 - large objects
 
-
-storage/lmgr
+
+storage/lmgr
 - lock manager
 
-
-storage/page
+
+storage/page
 - page manager
 
-
-storage/smgr
+
+storage/smgr
 - storage/disk manager
 
 
 
 
-
-access
+
+access
 - various data access methods
 
 
@@ -229,43 +230,43 @@ These control the way data is accessed in heap, indexes, and
 transactions.
 
 
-
-access/common
+
+access/common
 - common access routines
 
-
-access/gist
+
+access/gist
 - easy-to-define access method system
 
-
-access/hash
+
+access/hash
 - hash
 
-
-access/heap
+
+access/heap
 - heap is use to store data rows
 
-
-access/index
+
+access/index
 - used by all index types
 
-
-access/nbtree
+
+access/nbtree
 - Lehman and Yao's btree management algorithm 
 
-
-access/rtree
+
+access/rtree
 - used for indexing of 2-dimensional data
 
-
-access/transam
+
+access/transam
 - transaction manager (BEGIN/ABORT/COMMIT)
 
 
 
 
-
-nodes
+
+nodes
 - creation/manipulation of nodes and lists
 
 
@@ -283,23 +284,23 @@ These are used extensively in the parser, optimizer, and executor to
 store requests and data.
 
 
-
-utils
+
+utils
 - support routines
 
-4>
-
-utils/adt
+3>
+
+utils/adt
 - built-in data type routines
-4>
+3>
 
 This contains all the PostgreSQL builtin data types.
 
-4>
-
-utils/cache
+3>
+
+utils/cache
 - system/relation/function cache routines
-4>
+3>
 
 PostgreSQL supports arbitrary data types, so no data types are hard-coded
 into the core backend routines.
@@ -312,48 +313,48 @@ information cache.
 This last cache maintains information about all recently-accessed
 tables, not just system ones.
 
-4>
-
-utils/error
+3>
+
+utils/error
 - error reporting routines
-4>
+3>
 
 Reports backend errors to the front end.
 
-4>
-
-utils/fmgr
+3>
+
+utils/fmgr
 - function manager
-4>
+3>
 
 This handles the calling of dynamically-loaded functions, and the calling
 of functions defined in the system tables.
 
-4>
-
-utils/hash
+3>
+
+utils/hash
 - hash routines for internal algorithms
-4>
+3>
 
 These hash routines are used by the cache and memory-manager routines to
 do quick lookups of dynamic data storage structures maintained by the
 backend.
 
-4>
-
-utils/init
+3>
+
+utils/init
 - various initialization stuff
-4>
-4>
-
-utils/misc
+3>
+3>
+
+utils/misc
 - miscellaneous stuff
-4>
-4>
-
-utils/mmgr
+3>
+3>
+
+utils/mmgr
 - memory manager(process-local memory)
-4>
+3>
 
 When PostgreSQL allocates memory, it does so in an explicit context.
 Contexts can be statement-specific, transaction-specific, or
@@ -361,65 +362,70 @@ persistent/global.
 By doing this, the backend can easily free memory once a statement or
 transaction completes.
 
-4>
-
-utils/sort
+3>
+
+utils/sort
 - sort routines for internal algorithms
-4>
+3>
 
 When statement output must be sorted as part of a backend operation,
 this code sorts the tuples, either in memory or using disk files.
 
-4>
-
-utils/time
+3>
+
+utils/time
 - transaction time qualification routines
-4>
+3>
 
 These routines do checking of tuple internal columns to determine if the
 current row is still valid, or is part of a non-committed transaction or
 superseded by a new row.
 
 
-
-include
+
+include
 - include files
 
 
 There are include directories for each subsystem.
 
 
-
-lib
+
+lib
 - support library
 
 
 This houses several generic routines.
 
 
-
-regex
+
+regex
 - regular expression library
 
 
 This is used for regular expression handling in the backend, i.e. '~'.
 
 
-
-rewrite
+
+rewrite
 - rules system
 
 
 This does processing for the rules system.
 
 
-
-tioga
+
+tioga
 - unused (array handling?)
 
-
+
+
+
-Maintainer:    Bruce Momjian
-HREF="mailto:[email protected]">[email protected]a>)
-Last updated:      Mon Oct 27 11:01:08 EST 1997
+Maintainer:    Bruce Momjian (
+HREF="mailto:[email protected]">[email protected]A>)
+Last updated:      Tue Dec  9 17:56:08 EST 1997
 
+
+
+


diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html

index 04166222afb4ae25a6ccfecd43e742817f2de4a7..e286b6d8c6655940add16b0ba5355c872c51771a 100644 (file)

--- 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 
+HREF="../../include/nodes/primnodes.h"> 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 
+HREF="../../backend/rewrite">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 
+HREF="../../backend/executor">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:
+ 
+ShmemIndex - contains an index of all other shared memory
+structures, allowing quick lookup of other structure locations in shared
+memory
+Buffer Descriptors - control header for shared memory buffer block
+Buffer Blocks - block of table/index data shared by all backends
+Shared Buf Lookup Table - lookup to see if a requested buffer
+is already in the shared memory area
+LockTable - lock table structure, specifiying table, lock types, and
+backends holding or waiting on lock
+LockTable (lock hash) - lookup of LockTable structures using
+table name
+LockTable (xid hash) - lookup of LockTable structures using
+transaction id
+Proc Header - information about each backend, including locks held/waiting, 
+indexed by process id
+
+Each structure is created by calling 
+HREF="../../backend/storage/ipc/shmem.c"> 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 Momjian
-HREF="mailto:[email protected]">[email protected]a>)
-Last updated:      Mon Oct 27 11:01:08 EST 1997
+Maintainer:    Bruce Momjian (
+HREF="mailto:[email protected]">[email protected]A>)
+Last updated:      Tue Dec  9 17:56:08 EST 1997
 
+
+
+




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');
};

diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html
index 04166222afb4ae25a6ccfecd43e742817f2de4a7..e286b6d8c6655940add16b0ba5355c872c51771a 100644 (file)
--- 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 
+HREF="../../include/nodes/primnodes.h"> 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 
+HREF="../../backend/rewrite">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 
+HREF="../../backend/executor">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:
+ 
+ShmemIndex - contains an index of all other shared memory
+structures, allowing quick lookup of other structure locations in shared
+memory
+Buffer Descriptors - control header for shared memory buffer block
+Buffer Blocks - block of table/index data shared by all backends
+Shared Buf Lookup Table - lookup to see if a requested buffer
+is already in the shared memory area
+LockTable - lock table structure, specifiying table, lock types, and
+backends holding or waiting on lock
+LockTable (lock hash) - lookup of LockTable structures using
+table name
+LockTable (xid hash) - lookup of LockTable structures using
+transaction id
+Proc Header - information about each backend, including locks held/waiting, 
+indexed by process id
+
+Each structure is created by calling 
+HREF="../../backend/storage/ipc/shmem.c"> 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 Momjian
-HREF="mailto:[email protected]">[email protected]a>)
-Last updated:      Mon Oct 27 11:01:08 EST 1997
+Maintainer:    Bruce Momjian (
+HREF="mailto:[email protected]">[email protected]A>)
+Last updated:      Tue Dec  9 17:56:08 EST 1997
 
+
+
+




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');
};