backend update.

src/tools/backend/index.html

@@ -8,30 +8,30 @@ PostgreSQL Backend Flowchart
 </H1>
 <H2 ALIGN=CENTER>
 by Bruce Momjian
-</H2 ALIGN=CENTER>
+</H2>
 <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
+A query come into the backend via data packets coming in through TCP/IP
+and Unix Domain sockets.   It is 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
+identify the query type, and load the proper query-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.  
+complex query.  A <I>Utility</I> query is processed by a
+query-specific function in <A HREF="../../backend/commands">
+commands.</A> A complex query, like <B>SELECT, UPDATE,</B> and
+<B>DELETE</B> requires much more handling.
 <P>
-The parser takes the complex queries, and creates a
+The parser takes a complex query, 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
+<B>WHERE</B> clause qualification, which is filled in by
 <A HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A>
 Each table referenced in the query is represented by a <A
 HREF="../../include/nodes/parsenodes.h"> RangeTableEntry,</A> and they
@@ -39,33 +39,32 @@ are linked together to form the <I>range table</I> of the query, which 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 column references are converted to <A
-HREF="../../include/nodes/primnodes.h"> Resdom</A> entries, which are
+Certain queries, like <B>SELECT,</B> return columns of data.  Other
+queries, like <B>INSERT</B> and <B>UPDATE,</B> specify the columns
+modified by the query.  These column 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, which 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 Query fields.
+Other query elements, like aggregates(<B>SUM()</B>), <B>GROUP BY,</B>
+<B>ORDER BY</B> are also stored in their own Query 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
+The next step is for the Query to be modified by any <B>VIEWS</B> or
+<B>RULES</B> that may apply to the query.  This is performed by the <A
 HREF="../../backend/rewrite">rewrite</A> system.
 <P>
 The <A HREF="../../backend/optimizer">optimizer</A> takes the Query
-structure, and generates an optimal
-<A HREF="../..//include/nodes/plannodes.h">Plan</A> containing the
-primitive operations to be performed by the executor to execute the
-query.  The <A HREF="../../backend/optimizer/path">path</A> 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.
+structure and generates an optimal <A
+HREF="../..//include/nodes/plannodes.h">Plan,</A> which contains the
+operations to be performed to execute the query.  The <A
+HREF="../../backend/optimizer/path">path</A> module determines the best
+table join order and join type of each table in the RangeTable, using
+Query.qual(<B>WHERE</B> 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.
+returned to the client.
 <P>
 There are many other modules that support this basic functionality.
 They can be accessed by clicking on the flowchart.
@@ -73,39 +72,37 @@ 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:
 <UL> 
-<LI>ShmemIndex - contains an index of all other shared memory
-structures, allowing quick lookup of other structure locations in shared
-memory
+<LI>ShmemIndex - lookup of shared memory addresses using structure names
 <LI><A HREF="../../include/storage/buf_internals.h">Buffer
-Descriptors</A> - control header for shared memory buffer block
-
-<LI><A HREF="../../include/storage/buf_internals.h">Buffer Blocks</A>
-- 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><A HREF="../../include/storage/lock.h">LockTable</A>
-- 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
+Descriptors</A> - control header for buffer cache block
+<LI><A HREF="../../include/storage/buf_internals.h">Buffer Blocks</A> -
+data/index buffer cache block
+<LI>Shared Buf Lookup Table - lookup of buffer cache block address using
+table name and block number(<A HREF="../../include/storage/buf_internals.h">
+BufferTag</A>)
+<LI><A HREF="../../include/storage/lock.h">LockTable (ctl)</A> - lock table
+structure, specifiying table, lock types, and backends holding or
+waiting on lock
+<LI>LockTable (lock hash) - lookup of LockTable structures using relation
+and database object ids
 <LI>LockTable (xid hash) - lookup of LockTable structures using
 transaction id
 <LI><A HREF="../../include/storage/proc.h">Proc Header</A> - information
 about each backend, including locks held/waiting,  indexed by process id
 </UL>
 Each data structure is created by calling <A
-HREF="../../backend/storage/ipc/shmem.c"> ShmemInitStruct(),</A> and
-the lookup hashes are created by
+HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</A> and
+the lookups are created by
 <A HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A>
 <HR>
 <CENTER>
 <EM><BIG>
-Click on an item to see more detail or click
-<A HREF="backend_dirs.html">here</a> to see the full index.
-</EM></BIG>
+Click on an item to see more detail or
+<A HREF="backend_dirs.html">click</A> to see the full index.
+</BIG></EM>
 <BR>
 <BR>
-<IMG src="flow.jpg" usemap="#flowmap">
+<IMG src="flow.jpg" usemap="#flowmap" alt="flowchart">
 </CENTER>
 <MAP name="flowmap">
 <AREA COORDS="290,10,450,50" HREF="backend_dirs.html#main">