Attached patch cleans up the HTML code in tools/backend. This is

required for us to pull it into the main website. Same kind of fixes as
last time, just make sure things aren't violating the HTML standard. No
context changes at all.

Magnus Hagander

diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html
index cc4e16d9aa2929b5c8bc1bbc8be9a1f481dc42c2..433324bff130a238138cc437eca5433ad6e0b3c7 100644 (file)
--- a/src/tools/backend/backend_dirs.html
+++ b/src/tools/backend/backend_dirs.html
@@ -3,18 +3,17 @@
 PostgreSQL Backend Directories
 
 
- ALIGN=CENTER>
+
 PostgreSQL Backend Directories
 
- ALIGN=CENTER>
+
 by Bruce Momjian
 
-
-
 
+
 Click on any of the section headings to see the source code for that section.
 
-
+</P>
 
 
 bootstrap
@@ -94,7 +93,7 @@ This uses the parser output to generate an optimal plan for the
 executor.
 
 
-/path">
+_path">
 optimizer/path
 - creates path from parser output
 
@@ -106,7 +105,7 @@ and optimizer table statistics to evaluate each possible execution
 method, and assigns a cost to each.
 
 
-/geqo">
+_geqo">
 optimizer/geqo
 - genetic query optimizer
 
@@ -121,7 +120,7 @@ tables, it is faster.
 There is an option to control when this feature is used.
 
 
-/plan">
+_plan">
 optimizer/plan
 - optimizes path output
 
@@ -130,7 +129,7 @@ This takes the optimizer/path output, chooses the path with the
 least cost, and creates a plan for the executor.
 
 
-/prep">
+_prep">
 optimizer/prep
 - handle special plan cases
 
@@ -138,7 +137,7 @@ least cost, and creates a plan for the executor.
 This does special plan processing.
 
 
-/util">
+_util">
 optimizer/util
 - optimizer support routines
 
@@ -190,31 +189,31 @@ that pre-format user requests into a predefined format.
 These allow uniform resource access by the backend.
 
 
-/buffer">
+_buffer">
 storage/buffer
 - shared buffer pool manager
 
-/file">
+_file">
 storage/file
 - file manager
 
-/ipc">
+_ipc">
 storage/ipc
 - semaphores and shared memory
 
-/large_object">
+_large_object">
 storage/large_object
 - large objects
 
-/lmgr">
+_lmgr">
 storage/lmgr
 - lock manager
 
-/page">
+_page">
 storage/page
 - page manager
 
-/smgr">
+_smgr">
 storage/smgr
 - storage/disk manager
 
@@ -230,35 +229,35 @@ These control the way data is accessed in heap, indexes, and
 transactions.
 
 
-/common">
+_common">
 access/common
 - common access routines
 
-/gist">
+_gist">
 access/gist
 - easy-to-define access method system
 
-/hash">
+_hash">
 access/hash
 - hash
 
-/heap">
+_heap">
 access/heap
 - heap is use to store data rows
 
-/index">
+_index">
 access/index
 - used by all index types
 
-/nbtree">
+_nbtree">
 access/nbtree
 - Lehman and Yao's btree management algorithm 
 
-/rtree">
+_rtree">
 access/rtree
 - used for indexing of 2-dimensional data
 
-/transam">
+_transam">
 access/transam
 - transaction manager (BEGIN/ABORT/COMMIT)
 
@@ -289,7 +288,7 @@ store requests and data.
 - support routines
 
 
-/adt">
+_adt">
 utils/adt
 - built-in data type routines
 
@@ -297,7 +296,7 @@ store requests and data.
 This contains all the PostgreSQL builtin data types.
 
 
-/cache">
+_cache">
 utils/cache
 - system/relation/function cache routines
 
@@ -314,7 +313,7 @@ This last cache maintains information about all recently-accessed
 tables, not just system ones.
 
 
-/error">
+_error">
 utils/error
 - error reporting routines
 
@@ -322,7 +321,7 @@ tables, not just system ones.
 Reports backend errors to the front end.
 
 
-/fmgr">
+_fmgr">
 utils/fmgr
 - function manager
 
@@ -331,7 +330,7 @@ This handles the calling of dynamically-loaded functions, and the calling
 of functions defined in the system tables.
 
 
-/hash">
+_hash">
 utils/hash
 - hash routines for internal algorithms
 
@@ -341,17 +340,17 @@ do quick lookups of dynamic data storage structures maintained by the
 backend.
 
 
-/init">
+_init">
 utils/init
 - various initialization stuff
 
 
-/misc">
+_misc">
 utils/misc
 - miscellaneous stuff
 
 
-/mmgr">
+_mmgr">
 utils/mmgr
 - memory manager(process-local memory)
 
@@ -363,7 +362,7 @@ By doing this, the backend can easily free memory once a statement or
 transaction completes.
 
 
-/sort">
+_sort">
 utils/sort
 - sort routines for internal algorithms
 
@@ -372,7 +371,7 @@ When statement output must be sorted as part of a backend operation,
 this code sorts the tuples, either in memory or using disk files.
 
 
-/time">
+_time">
 utils/time
 - transaction time qualification routines
 
@@ -419,13 +418,11 @@ This does processing for the rules system.
 - unused (array handling?)
 
 
- SIZE="2" NOSHADE>
+
 
 Maintainer:    Bruce Momjian (
 HREF="mailto:[email protected]">[email protected])
 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 78b8b8e5fac562846c81f50d56390273eacfc5e2..241c4bb5d57bf57fa3901256c0b7484dfeaf101e 100644 (file)

--- a/src/tools/backend/index.html
+++ b/src/tools/backend/index.html
@@ -3,42 +3,40 @@
 How PostgreSQL Processes a Query
 
 
- ALIGN=CENTER>
+
 How PostgreSQL Processes a Query
 
- ALIGN=CENTER>
+
 by Bruce Momjian
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
-<CENTER><EM>
+
 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
@@ -49,13 +47,13 @@ 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.
+HREF="../../include/nodes/parsenodes.h">SelectStmt.</P><P>
 
 
 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.</P><P>
 
 
 The parser takes a complex query, and creates a
@@ -67,7 +65,7 @@ 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.
+transformFromClause().  Query.rtable holds the query's range table.</P><P>
 
 
 Certain queries, like SELECT, return columns of data.  Other
@@ -78,16 +76,16 @@ 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 
-HREF="../../backend/parser/parse_target.c">transformTargetList().
+HREF="../../backend/parser/parse_target.c">transformTargetList().</P><P>
 
 
 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.</P><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 
-HREF="../../backend/rewrite">rewrite system.
+HREF="../../backend/rewrite">rewrite system.</P><P>
 
 
 The optimizer takes the Query
@@ -96,18 +94,17 @@ 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.</P><P>
 
 
 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.
+can be accessed by clicking on the flowchart.</P>
 
 
 
@@ -117,19 +114,20 @@ 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
+ShmemIndex - lookup shared memory addresses using structure names
 Buffer
-Descriptor - control header for buffer cache block
+Descriptor - control header for buffer cache block
 Buffer Block -
-data/index buffer cache 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)
+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).
+HREF="../../include/storage/lock.h">LOCKMETHODCTL).
 MultiLevelLockTable (lock hash) - the 
 HREF="../../include/storage/lock.h">LOCK structure, looked up using
 relation, database object ids(
@@ -137,31 +135,29 @@ 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.
+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.
+contains a pointer to the backend's PROC.lockQueue.
 Proc Header - information
-about each backend, including locks held/waiting, indexed by process id
+about each backend, including locks held/waiting, indexed by process id
 
 
-Each data structure is created by calling 
+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().
+HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</P>
 
 
- SIZE="2" NOSHADE>
+
 
-
 Maintainer:    Bruce Momjian (
 HREF="mailto:[email protected]">[email protected])
 Last updated:      Mon Aug 10 10:48:06 EDT 1998
-
 
 
 




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 78b8b8e5fac562846c81f50d56390273eacfc5e2..241c4bb5d57bf57fa3901256c0b7484dfeaf101e 100644 (file)
--- a/src/tools/backend/index.html
+++ b/src/tools/backend/index.html
@@ -3,42 +3,40 @@
 How PostgreSQL Processes a Query
 
 
- ALIGN=CENTER>
+
 How PostgreSQL Processes a Query
 
- ALIGN=CENTER>
+
 by Bruce Momjian
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
-<CENTER><EM>
+
-
+
 
 
-
+
 
 
 A query comes to the backend via data packets arriving through TCP/IP or
@@ -49,13 +47,13 @@ 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.
+HREF="../../include/nodes/parsenodes.h">SelectStmt.</P><P>
 
 
 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.</P><P>
 
 
 The parser takes a complex query, and creates a
@@ -67,7 +65,7 @@ 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.
+transformFromClause().  Query.rtable holds the query's range table.</P><P>
 
 
 Certain queries, like SELECT, return columns of data.  Other
@@ -78,16 +76,16 @@ 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 
-HREF="../../backend/parser/parse_target.c">transformTargetList().
+HREF="../../backend/parser/parse_target.c">transformTargetList().</P><P>
 
 
 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.</P><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 
-HREF="../../backend/rewrite">rewrite system.
+HREF="../../backend/rewrite">rewrite system.</P><P>
 
 
 The optimizer takes the Query
@@ -96,18 +94,17 @@ 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.</P><P>
 
 
 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.
+can be accessed by clicking on the flowchart.</P>
 
 
 
@@ -117,19 +114,20 @@ 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
+ShmemIndex - lookup shared memory addresses using structure names
 Buffer
-Descriptor - control header for buffer cache block
+Descriptor - control header for buffer cache block
 Buffer Block -
-data/index buffer cache 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)
+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).
+HREF="../../include/storage/lock.h">LOCKMETHODCTL).
 MultiLevelLockTable (lock hash) - the 
 HREF="../../include/storage/lock.h">LOCK structure, looked up using
 relation, database object ids(
@@ -137,31 +135,29 @@ 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.
+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.
+contains a pointer to the backend's PROC.lockQueue.
 Proc Header - information
-about each backend, including locks held/waiting, indexed by process id
+about each backend, including locks held/waiting, indexed by process id
 
 
-Each data structure is created by calling 
+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().
+HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</P>
 
 
- SIZE="2" NOSHADE>
+
 
-
 Maintainer:    Bruce Momjian (
 HREF="mailto:[email protected]">[email protected])
 Last updated:      Mon Aug 10 10:48:06 EDT 1998
-
 
 
 




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